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Executive  Summary 

ESTIMATING  SPARES  REQUIREMENTS  FOR 
SPACE  STATION  FREEDOM 

Using  the  M-SPARE  Model 


Space  Station  Freedom  (SSF)  will  be  a  manned  research  laboratory  designed  by 
NASA  to  orbit  200  miles  above  the  Eart for  30  years.  To  ensure  the  safety  of  its 
crew  and  the  success  of  its  missions,  the  station  will  need  additional  parts  (spares)  to 
replace  failed  equipment.  Because  spares  are  expensive  and  SSF  budgets 
constrained,  NASA  needed  a  method  to  determine  the  optimal  spares  inventory  for  a 
specified  cost. 

The  Multiple  Spares  Prioritization  and  Availability  to  Resource  Evaluation 
(M-SPARE)  model  provides  NASA  that  capability.  M-SPARE  implements  a  method 
that  considers  the  unique  characteristics  of  SSF,  applies  across  all  SSF  organi¬ 
zational  levels,  and  ensures  the  best  station  performance  for  any  specified  level  of 
investment.  M-SPARE  has  evolved  significantly  over  its  3-year  life  and  now 
addresses  most  SSF  spares  issues.  NASA  is  currently  using  M-SPARE  to  answer 
three  basic  questions  concerning  SSF: 

•  What  spares  does  it  need? 

•  When  does  it  need  them? 

•  How  much  will  they  cost? 

This  guide  describes  the  M-SPARE  methodology,  products,  capabilities,  and 
operations  necessary  to  answer  those  questions. 

Methodology  —  The  core  of  M-SPARE  is  its  selection  methodology  that  links 
station  performance  to  spares  resource  requirements.  Station  performance  (we  term 
it  availability)  is  defined  as  the  probability  that  no  critical  system  becomes 
inoperative  over  the  resupply  cycle  (time  interval  between  shuttle  flights)  for  lack  of 
an  orbital  replaceable  unit  (ORU)  spare.  The  annual  spares  resource  requirement 
can  be  a  single  resource  such  as  budget  dollars,  weight  the  shuttle  can  carry,  station 
storage  volume,  or  it  can  be  a  combination  of  resoiurces.  M-SPARE  is  based  on  a 
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marginal-analysis  approach.  Spares  are  ranked  in  order  of  decreasing  benefit  per 
cost  (essentially  the  improvement  provided  to  station  availability  per  unit  resoiu-ce) 
and  added,  in  that  order,  to  the  inventory  until  a  target  resource  expenditure  or 
station  availability  is  reached.  Besides  resources,  the  model  also  considers  the  ORU’s 
failure  rate,  frequency  of  shuttle  resupply,  repair  time,  procurement  lead  time,  and 
assembly  sequence. 

Products  —  M-SPARE  develops  three  key  products  over  a  specified  period  of 
the  station’s  life.  First,  it  specifies  the  entire  range  (a  plotted  curve)  of  how  BSP’s 
availability  changes  as  annual  spares  resource  expenditures  change.  Every  point  on 
the  curve  corresponds  to  an  optimal  spares  mix  that  maximizes  station  availability. 
Second,  the  model  develops  a  list  of  required  spares  by  year  based  upon  a  user- 
specified  station  availability  target  or  resource  constraints.  Finally,  the  model 
converts  spares  requirements  over  a  period  of  station  life  to  current  funding 
estimates  for  the  next  9  fiscal  years. 

Other  Capabilities  —  To  conserve  weight  and  volume,  the  model  optimizes  the 
spares  storage  location  so  that  only  the  most  vital  spares  are  stored  on  orbit.  To 
resolve  conflicting  resource  constraints,  the  model  develops  a  range  of  tradeoff 
options  enabling  users  to  determine  a  balanced  solution.  To  help  produce  complete 
budget  estimates,  the  model  estimates  spares  requirements  for  all  types  of  ORUs 
(critical  and  noncritical).  To  adapt  to  changing  resource  constraints,  the  model 
presents  a  range  of  possibilities  and  their  respective  resource  conservation. 

Operations  —  M-SPARE  operates  on  a  personal  computer,  making  the  model 
accessible  to  SSF  users.  It  contains  a  menu-driven  interface  so  that  users  can  easily 
prepare  inputs,  run  the  model,  and  analyze  results.  The  model’s  data  requirements 
are  based  upon  existing  user  data  base  information  so  that  the  model  is  responsive  to 
current  conditions.  It  is  an  anal3d;ic  model  that  generates  solutions  in  minutes. 

With  the  use  of  M-SPARE,  NASA  obtains  three  important  benefits: 

•  A  comprehensive  approach  that  helps  to  ensure  station  spares  are  available 
when  needed 

•  A  consistent  approach  for  the  many  organizations  that  are  involved  with 
SSF 

•  A  defensible  approach  that  links  spares  budgets  to  station  availability,  the 
ultimate  program  goal. 


VI 


CONTENTS 


Page 

Acknowledgments .  iii 

Executive  Summary  .  v 

Tables  .  xi 

Figures  .  xii 

Exhibits  .  xiii 

Chapter  1.  Introduction  .  1-1 

Users  Guide  Organization .  1-4 

Why  Does  The  Station  Need  Spares?  .  1-6 

Why  This  Approach?  .  1-7 

A  Deterministic  Example  .  1-8 

Basic  Model  Assumptions  .  1-10 

Users  and  Uses  .  ]  -13 

Chapter  2.  Installation  and  Demonstration  .  2-1 

Installation .  2-1 

Interface  Operation  .  2-1 

View  .  2-2 

Options  .  2-3 

Wear .  2-4 

Run  .  2  4 

Exit .  2-4 

Quick  Test  Drive  .  2-4 

First  Model  Year:  FY98  .  2-5 

Model  Year  2:  FY99  .  2-5 

Model  Year  3:  FYOO  .  2-7 

Model  Years  4  to  7:  FY01toFY05  .  2-7 

PC  Requirements  .  2-10 

Chapter  3.  Spares  Prioritization  Overview .  3-1 

Station  Availability  .  3-2 

Spares  Prioritization  Across  ORUs  .  3-3 

Marginal  Benefit-to-Cost  Ratio  .  3-3 

vii 


CONTENTS  (Continued) 


Page 

Example  ofthe  Prioritization  Process .  3-4 

Multiple  Resource  Optimization  .  3-5 

Chapter  4.  Detailed  ORU  Multi-Echelon  Methodology  .  4-1 

The  ORU  Multi-Echelon  Tradeoff .  4-2 

An  Example  of  the  Maintenance  Process  .  4-2 

Probability  Distribution  of  Unserviceable  Spares  .  4-5 

Multi-Echelon  ORU  PSN .  4-6 

Multi-Echelon  Tradeoff .  4-9 

ORU  Extensions  .  4-10 

Replaced  Condemnations  .  4-11 

Element  Launch  and  Assembly  Impacts  .  4-13 

Alternative  ORU  Failure  Patterns  .  4-17 

ORUs  with  Ground  Spares  Only  .  4-17 

Chapter  5.  Model  ORU  Input  Data  .  5-1 

Input  File  Description  .  5-1 

Description  .  5-1 

Unit  Resources .  5-2 

Miscellaneous  .  5-2 

Maintenance  Factors  .  5-2 

Demand  Factors  . 5-5 

Input  File  Format  .  5-7 

Input  File  Summary  .  5-7 

Chapters.  Model  Options  .  6-1 

Logistics  Cycle  Delta  .  6-1 

Starting  Spares  .  6-1 

Number  of  Passes  .  6-3 

Maximum  Availability  .  6-3 

Plot  .  6-3 

Trace  Information  .  6-4 

Number  of  Model  Years  .  6-4 

First  Model  FY .  6-4 

First  Budget  FY .  6-5 

Funding  Split  .  6-6 

Baseline  Fiscal  Year .  6-6 

Price  Escalator  Percent  .  6-6 

LOTUS  .  6-6 

QPA  Input  Format  .  6-6 

viii 


CONTENTS  (Continued) 


Decrement  Days  .  6-7 

Wear  Wake  .  6-8 

Drive  Location  .  6-8 

Number  of  Criticality  Codes  .  6-8 

Cumulative  POP  Marks  Table  .  6-8 

Spread  Vectors  .  6-9 

Launch  Schedule  Table  .  6-9 

Chapter?.  Model  Operation  and  Analysis  .  7-1 

Single-Pass  Mode  .  7-4 

Multiple-Pass  Mode  .  7-6 

Ground-Stock-Only  Mode  .  7-10 

Minimum  Spares  Evaluation  Mode .  7-10 

Global  ORUPOS  Mode  .  7-10 

Chapters.  Model  Outputs  .  8-1 

The  Budget  Output  Files  (BUDGET.RPT)  .  8-1 

Annual  Budgets  by  Model  Year  and  Criticality  .  8-1 

Gross  Spares  Requirements  by  Fiscal  Year  Table  .  8-1 

Net  Spares  with  Replaced  Condemnations  by  Fiscal  Year  Table  . .  8-2 

Spares  Budget  Estimates  by  Fiscal  Year  Table  .  8-2 

Detailed  Spares  Requirement  Files  (OUT.RPT) . 8-3 

Element  Launch  Schedule  Table  .  8-4 

QPA  Profile  Table  .  8-4 

Demand  Summary  Table .  8-5 

User  Inputs  and  Options  Table .  8-6 

ORU  Input  Data  Table  .  8-7 

Pass  Solutions  Table .  8-7 

Spares  Mix  for  Solution  Point  Table  .  8-8 

Distributed  Systems  Results  Table  .  8-8 

Resource-Versus-Availability  Curve  Table .  8-9 

Resource  Summary  Table  .  8-9 

Chapter  9.  M-SPARE  Use  for  the  Program  Operating  Plan  .  9-1 

Spares  Requirements  Product  .  9-2 

Constrained  Budget  Product .  9-2 

How  to  Target  M-SPARE  to  Match  POP  Marks  .  9-3 

Targeting  Methodology  .  9-4 

Development  and  Operational  Product  .  9-6 


IX 


CONTENTS  (Continued) 


Page 

Chapter  10.  The  Wear  Preprocessor  .  10-1 

Introduction  .  10-1 

Program  Logic  .  10-2 

Input  .  10-3 

Processing  .  10-6 

Output  .  10-6 

Utilization  of  Preprocessor  Output  .  10-8 

Integration  with  M-SPARE  .  10-8 

Appendix  A:  Spares  Optimization  Proof  .  A-1  — A-8 

Appendix  B:  Glossary  .  B-1  — B-4 


TABLES 


Page 

1-1.  Comparison  ofTwo  Spares’ Selection  Approaches  .  1-7 

l-2a.  Spares  Requirements  (Deterministic  Failures)  .  1-9 

l-2b.  Spares  Requirements  (Deterministic  Failures)  .  1-9 

l-2c.  Spares  Reqmrements  (Deterministic  Failures)  .  1-11 

3- 1.  ExampleofSpaceStation  Availability  Cost  Curve  .  3-4 

4- 1.  Multi-Echelon  Evaluation .  4-7 

4-2.  ORU  PSN  for  Combinations  of  On-Orbit  and  Ground  Spares  .  4-8 

4-3.  ORU  Multi-Echelon  Tradeoffs  .  4-10 

4-4.  Spares  Requirements  (Deterministic  Failures)  .  4-12 

4- 5.  Comparison  of  Demand  Distributions  .  4-18 

5- 1.  Summary  of  MSPAREIN.RPT  Data  Base  Fields  .  5-8 

8- 1.  Table  Layout  of  Out.RPT  File .  8-5 

9- 1.  Investment  Input  Versus  Budget  Output  .  9-3 


FIGURES 


Page 

1-1.  Resource-Versus-Station-Availability  Curve  .  1-2 

1-2.  Overview  ofCreating  Budget  Requirements  .  1-3 

1-3.  Outlays  Meet  Future  Spares  Requirements  for  FY98  .  1-11 

4-1 .  Maintenance  Process  (Estimating  unserviceable  ORU 

spares  over  time)  .  4-3 

4-2.  Unserviceable  ORU  Spares  at  Shuttle  Launch .  4-4 

6-1.  Key  Input  Variables  in  OPTIONS.RPT  File  .  6-5 

6-2.  QPA  Format  Options  .  6-7 


xii 


EXHIBITS 


Page 

2-1.  Interface  Menu  .  2-2 

2-2.  View  Menu  .  2-3 

2-3.  Resource- Versus-Ground  Availability  Curve:  FY98  .  2-6 

2-4.  Resource- Versus-Ground  Availability  Curve:  FY99  .  2-6 

2-5.  Iterative-Price-Versus-Weight  Tradeoff  Solutions:  FYOO  .  2-8 

2- 6.  Annual  Spares  Upweight  Estimates .  2-9 

3- 1.  Resource  TradeoffPossibilities  at  95  Percent  Availability  .  3-7 

4- 1.  Example  Station  ORU  .  4-14 

5- 1.  Examples  of  ORU  Data  Base  .  5-3 

6- 1.  Model  OPTIONS.RPT  File  .  6-2 

7- 1.  Criticality  Code  Query  .  7-2 

7-2.  Initial  Year  Menu  .  7-3 

7-3.  Model  Rim  Options  Menu  .  7-3 

7-4.  Single-Pass  Mode  .  7-5 

7-5.  Multiple-Pass  Mode  .  7-7 

7-6.  Pass  Solutions  Table .  7-9 

7-7.  Ground-Stock-Only  Mode  .  7-11 

7- 8.  Global  ORU  POS  Mode  .  7-11 

8- 1.  Gross  Spares  Requirements  by  Fiscal  Year .  8-2 

8-2.  Net  Spares  Requirements  .  8-2 

xiii 


EXHIBITS  (Continued) 


Page 

8-3.  Spares  Budget  Estimates  by  Fiscal  Year  .  8-3 

8-4.  Element  Launch  Schedule  Table  .  8-6 

8-5.  QPA  Profile  Table  .  8-6 

8-6.  Demand  Summary  Table  .  8-7 

8-7.  Spares  Mix  for  Solution  .  8-8 

8-8.  Distributed  Systems  Results  Table  .  8-9 

8- 9.  Resource  Summary  Table  .  8-10 

9- 1.  Targeting  M-Spare  to  POP  Marks  .  9-5 

9-2.  Estimating  the  Proportion  of  Development  Spares  .  9-7 

10-1.  Options  for  the  Wear  Preprocessor  .  10-2 

10-2.  Sample  Input  Data  File  .  10-4 

10-3.  Output  For  Battery  ORU .  10-7 

10-4.  Failure  Rates  .  10-9 

10-5.  Time  to  Failure  .  10-9 

10-6.  Demands  Per  Month  .  10-10 

10-7.  Condemnations  Per  Month  .  10-10 

10-8.  Weight  Per  Month .  10-11 


XIV 


CHAPTER  1 


INTRODUCTION 


Space  Station  Freedom  (SSF)  will  be  a  manned  orbital  research  laboratory  with 
a  planned  life  cycle  of  30  years.  The  station  will  orbit  200  miles  above  Earth,  and  its 
only  life  line  to  the  planet  will  be  a  few  shuttle  resupply  flights  each  year.  Although 
the  original  station  components  are  highly  reliable,  spares  are  necessary  to  replace 
the  possible  component  failures  that  astronauts  cannot  repair.  Thus,  spares  are 
necessary  to  ensure  maximum  station  performance  and  minimal  crew  risk.  NASA 
asked  LMI  to  develop  a  model  to  answer  three  basic  questions  about  SSF: 

•  What  spares  are  needed? 

•  When  are  they  needed? 

•  How  much  Mali  they  cost? 

In  this  guide,  we  present  a  methodology  that  prioritizes  spares  selection  as  the 
station  is  assembled  and  operated.  Optimal  spares  requirements  are  converted  into 
funding  requirements,  which  drive  NASA  spares  budgets. 

Over  the  past  3  years,  we  developed  a  model  to  address  most  of  SSPs  reparable 
spares  issues.  It  is  called  the  Multiple  Spares  Prioritization  and  Availability  to 
Resource  Evaluation  (M-SPARE)  model.  The  core  of  the  model  is  its  spares  selection 
methodology  that  links  station  performance  to  spares  resource  requirements.  Station 
performance  (what  we  term  availability)  is  defined  as  the  probability  that  no  critical 
system  becomes  inoperative  over  the  resupply  logistics  cycle  (the  interval  between 
shuttle  resupply  laimches)  for  lack  of  an  orbital  replaceable  imit  (ORU)  spare.  The 
spares  resource  requirement  can  be  a  single  resource  (such  as  budget  dollars,  weight 
the  shuttle  can  carry,  or  station  storage  volume)  or  a  combination  of  resources. 

The  M-SPARE  model  is  based  on  a  marginal-analysis  approach.  Spares  are 
ranked  in  order  of  decreasing  benefit  per  cost  (essentially  the  improvement  provided 
to  station  availability  per  unit  resource)!  and  added,  in  the  same  order,  to  the 


iFor  technical  reasons,  M-SPAREs  actually  considers  the  logarithm  of  the  increase  in 
availability.  See  Appendix  A. 
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inventory  until  a  target  resource  expenditure  or  station  availability  is  reached. 
Besides  resources,  the  model  also  considers  the  ORU’s  failure  rate,  frequency  of 
shuttle  resupply,  repair  time,  proc'U’ement  time,  and  assembly  sequence. 

The  M-SPARE  model  develops  three  key  products.  First,  it  specifies  how  SSF 
availability  changes  as  resource  expenditures  change  (Figure  1-1).  Every  point  on 
the  plotted  curve  corresponds  to  an  optimal  spares  mix  that  maximizes  availability 
for  a  given  resource  level.  Second,  the  model  develops  a  list  of  required  spares  by  year 
based  upon  a  user-specified  station  availability  target  or  resource  target.  Finally,  the 
model  converts  spares  requirements  over  a  period  of  station  life  to  current  funding 
estimates  that  shape  NASA  spares  budgets  for  the  next  9  fiscal  years. 


FIG.  1-1.  RESOURCE-VERSUS-STATION-AVAILABIUTY  CURVE 
(Critical  on-orbit  ORUs) 

Model  operations  start  with  two  basic  inputs  —  annual  station  configurations 
and  annual  station  targets  (see  Figure  1-2).  The  SSF  configuration  specifies  the  ORU 
criticality  type,  population,  and  characteristics  such  as  failure  rates  and  ground 
repair  times.  The  SSF  targets  help  specify  the  size  of  the  required  spares  inventory. 
Users  can  specify  availability,  price,  weight,  or  volume  targets  or  any  target 
combination.  Given  those  inputs,  M-SPARE  automatically  determines  the  gross 
spares  requirement  for  successive  years  of  the  station’s  life  —  the  total  number  of 
spares  of  each  item  needed  in  the  inventory  to  reach  the  specified  target.  Next,  the 
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model  estimates  the  annual  difference,  by  item,  between  gross  requirements  and 
available  assets  (spares  procured  in  previous  years).  That  difference  is  the  net  spares 
requirement.  The  accumulation  of  each  item’s  net  spares  requirement  times  the  unit 
price  then  drives  the  estimates  for  the  budgets  in  the  fiscal  years  a  procurement  lead 
time  earlier.  We  chose  that  fiscal  year  format  so  that  M-SPARE  outputs  are 
consistent  with  the  SSF  general  budget  process.  [Note:  When  we  refer  to  budgets,  we 
really  mean  outlays  that  accrue  in  a  specific  fiscal  year  as  opposed  to  obligations  that 
can  be  spent  over  several  years.] 


Assembly  Sequence 


FY96  FY97  FY98 


FY94  FY9S  FY96  FY97  FY98 


FIG.  1-2.  OVERVIEW  OF  CREATING  BUDGET  REQUIREMENTS 


1-3 


In  addition,  M-SPARE  has  the  following  capabilities: 

•  It  determines  the  optimal  storage  location  (on  orbit  or  ground)  for  each  type 
of  spare.  If  on-orbit  storage  is  not  available,  users  can  override  that 
optimization  and  specify  ground  storage  only. 

•  It  balances  conflicting  resource  constraints  such  as  spares  budget  dollars 
and  shuttle  weight  limitations. 

•  It  estimates  spares  weight  and  volume  projections  to  resupply  all  failures 
throughout  each  year. 

•  It  produces  a  combined  budget  for  all  types  of  ORUs  (e.g..  Criticality 
Codes  1, 2,  and  3). 

•  It  constrains  spares  levels  to  a  specified  annual  budget. 

•  It  estimates  reparable  spares  requirements,  including  condemnations  (a 
broken  spare  that  can  no  longer  be  fixed). 

•  It  estimates  spares  based  upon  ORU  failures  from  random  and  time- 
dependent  processes  (e.g.,  wear-related  failiires  that  usually  occur  when  an 
ORU  is  a  certain  age). 

•  It  estimates  the  benefit  (availability  improvement  or  the  cost  savings)  of 
changing  the  resupply  frequency  or  using  common  ORUs  for  more  than  one 
application. 

•  It  generates  most  solutions  within  minutes  on  IBM-compatible  personal 
computers  (PCs). 

USERS  GUIDE  ORGANIZATION 

In  this  guide,  we  describe  the  M-SPARE  model  methodology,  why  that 
methodology  is  used,  and  the  algorithms  within  the  computer  code.  We  offer  further 
guidance  to  the  user  to  install  and  operate  the  model,  describe  the  model’s  data  inputs 
and  how  to  modify  them,  and  present  sample  data  outputs  and  what  they  mean.  In 
addition,  we  describe  how  to  modify  model  assumptions  to  perform  various  types  of 
analyses.  The  remainder  of  this  Chapter  and  Chapter  2  present  an  overview  of  the 
model  methodology  and  operation.  Chapters  3  and  4  concentrate  on  the  technical 


1-4 


details  of  the  methodology.  The  remaining  chapters  present  details  on  how  to  use  the 
model.  The  following  paragraphs  describe  each  chapter  in  more  detail; 

•  Chapter  1  —  Introduction.  In  the  rest  of  this  chapter,  we  discuss  why  the 
station  needs  spares  and  present  simple  examples  to  illustrate  why  the 
M-SPARE  methodology  outperforms  a  more  traditional  sparing  approach. 
We  also  outline  the  overall  model  methodology. 

•  Chapter  2  —  Installation  and  Demonstration.  In  this  chapter,  we  discuss 
how  to  install  the  model  on  a  PC  and  guide  the  user  through  a  test  drive. 
That  whole  process  takes  about  10  minutes  and  gives  an  overview  of  the 
model’s  operation  and  capability.  We  also  discuss  the  model  user  interface 
that  helps  users  prepare  input,  operate  the  model,  and  analyze  results. 

•  Chapters  —  Spares  Prioritization  Overview.  In  this  chapter,  we  provide  an 
overview  of  the  spares  optimization  methodology  and  capabilities. 
Specifically,  we  discuss  station  availability,  the  optimal  spares  selection 
process,  and  resource  tradeoff  analyses. 

•  Chapter 4  —  Detailed  ORU Multi-Echelon  Methodology.  In  this  chapter,  we 
present  the  details  of  the  ORU  multi-echelon  tradeoff,  the  basic  bmlding 
block  of  the  spares  selection  process.  That  tradeoff  considers  a  host  of  factors 
such  as  on-orbit  failiire  rates,  times  required  to  repair  or  replace  ORUs,  and 
shuttle  flight  frequency.  The  final  result  is  an  optimal  tradeoff  that  decides 
the  mix  of  spares  to  be  stored  on  orbit  and  on  the  ground  and  the  resulting 
station  availability. 

•  Chapters  —  Model  ORU  Input  Data.  This  chapter  discusses  the  input  data 
required  for  the  model  and  how  to  create  or  modify  those  data. 

•  Chapter  6  —  Model  Options.  This  chapter  discusses  the  procedure  for  setting 
basic  model  options  that  change  infrequently  such  as  the  element  launch 
schedule  or  the  budget  time  horizon. 

•  Chapter  7  —  Model  Operation  and  Analysis.  In  this  chapter,  we  discuss  the 
steps  required  to  run  the  model  and  the  different  modes  of  operation.  We 
also  discuss  the  types  of  analyses  —  estimating  spares  mixes,  using  multiple 
resources,  developing  resource  tradeoffs,  and  examining  alternative  solu¬ 
tions. 

•  Chapter  8  —  Model  Outputs.  This  chapter  presents  model  outputs  and 
describes  how  to  interpret  them.  The  model  produces  two  files.  One  is  a 
budget  file  that  summarizes  spares  and  funding  requirements  over  time;  the 
other  is  a  detailed  output  file  that  focuses  on  displaying  pertinent  input, 
intermediate  results,  and  output  data  used  in  the  model. 
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•  Chapter  9  —  M-SPARE  Use  for  the  Program  Operating  Plan  (POP).  In  this 
chapter,  we  discuss  how  to  use  M-SPARE  for  its  major  purpose:  to  produce 
spares  and  funding  requirements  for  a  POP  cycle  (part  of  NASA’s  overall 
budget  process). 

•  Chapter  10  —  The  Wear  Preprocessor.  In  this  chapter,  we  discuss  how  the 
model  deals  with  ORUs  that  wear  out.  Besides  the  standard  random 
failures,  ORUs  may  also  exhibit  a  failure  mode  after  being  in  operation  for  a 
specific  period  of  time.  M-SPARE  uses  a  preprocessor  that  simulates  wear- 
out  and  random  failures  over  15  years  of  the  station’s  life.  The  preprocessor 
then  produces  a  time-dependent,  aggregate  failure  rate  that  M-SPARE  uses 
in  the  spares  prioritization. 

•  Appendix  A  —  Spares  Optimization  Proof.  This  appendix  presents  a 
mathematical  proof  for  the  model’s  optimization  methodology. 

•  Appendix  B  —  Glossary.  This  glossary  defines  the  acronyms  used 
throughout  this  guide. 

WHY  DOES  THE  STATION  NEED  SPARES? 

A  basic  question  is  why  does  a  station  whose  components  fail  every  30  years  or 
more  on  average  need  spares?  That  is  especially  true  when  you  consider  that  even  if 
an  item  fails,  the  station  has  redundant  backup  systems  that  will  work  in  its  place. 
The  question  seems  reasonable  until  you  start  examining  the  numbers. 

Suppose  individual  ORUs  last,  on  average,  for  30  years.  That  means  some  will 
operate  longer  and,  more  importantly,  some  will  operate  less.  If  we  assume  a 
standard  failure  rate  probability  distribution  (Poisson),  there  is  a  6  percent  chance 
that  any  given  item  will  fail  in  the  first  2  years.  When  you  then  consider  that  an 
ORU  is  installed  in  five  separate  locations  on  the  station,  the  chance  of  a  failure  in 
2  years  increases  to  30  percent.  Add  to  that  failures  caused  by  accidents  or  the  harsh 
space  environment  and  the  chance  of  failure  may  increase  to  60  percent.  Next, 
consider  that  if  the  station  does  have  a  failure,  it  could  wait  2  to  5  years  before  the 
failed  item  can  be  returned  to  Earth,  repaired  or  replaced,  and  then  delivered  back  to 
the  station.  (Astronauts  will  have  limited  repair  capability.)  Even  with  redimdant 
systems,  that  is  a  long  time  to  wait  with  only  a  backup  between  you  and  an 
emergency  evacuation.  Finally,  if  the  chance  that  one  ORU  fails  is  60  percent,  then 
the  chance  of  a  failure  among  SSF’s  hundreds  of  ORUs  is  certain.  In  fact,  the 
question,  “Do  you  need  a  spare?”  quickly  changes  to  “How  many  spares  do  you  need?” 
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Estimating  how  many  spares  the  station  requires  becomes  even  more  com¬ 
plicated  when  you  consider  many  spares  are  extremely  expensive  (in  the  $500,000  to 
$1  million  dollar  range)  and  that  spares  budgets  are  very  limited.  You  also  must 
decide  what  spares  can  be  brought  and  stored  in  the  station  and  what  spares  must 
stay  on  the  ground  because  shuttle  weight  and  station  storage  volume  is  also  severely 
constrained.  All  those  considerations  went  into  developing  the  M-SPARE  meth¬ 
odology. 

WHY  THIS  APPROACH? 

Another  question  is,  "‘What  does  this  method  do  that  other  approaches  fail  to 
do?”  The  answer  is  illustrated  in  Table  1-1.  That  table  compares  two  ways  of 
selecting  spares  for  a  hypothetical  station  that  contains  only  two  critical  ORUs.  The 
traditional  approach  treats  all  ORUs  the  same.  It  selects  spares  so  that  each  ORU 
has  a  95  percent  chance  of  having  at  least  as  many  spares  as  demands  (see  top  of 
Table  1-1).  Space  station  availability  is  the  probability  that  no  ORU  is  inoperative 
for  lack  of  a  spare,  which  is  the  product  of  the  two  probabilities  (90  percent).  That 
means  both  ORUs  are  operating  90  percent  of  the  time.  The  station  resource 
expenditure  is  $13:  $3  for  three  spares  of  ORU  A  at  $1  each,  and  $10  for  two  spares  of 
ORU  B  at  $5  each. 


TABLE  1-1 

COMPARISON  OF  TWO  SPARES'  SELECTION  APPROACHES 


Traditional  Targets:  0.95 

Parameter 

ORU  A 

Cost  =  $1 

ORUB 

Cost  =  $5 

Space  station 

Performance  probability 

0.95 

0.95 

90% 

Number  of  spares 

3 

2 

— 

Cost($) 

3 

10 

13 

Optimal:  A  Better  Way 

Performance  probability 

0.98 

0.93 

91% 

Number  of  spares 

4 

1 

— 

Cost($) 

4 

5 

9 
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However,  there  is  a  better  way  to  determine  a  spares  mix.  The  approach  focuses 
on  how  well  the  station  as  a  system  of  ORUs  is  performing  as  opposed  to  how  well 
each  ORU  is  performing.  Thus,  the  system  approach  does  not  treat  all  ORUs  the 
same  but  considers  that  their  failure  rates  and  costs  are  different.  Table  1-1  (bottom 
section)  demonstrates  that  by  slightly  changing  the  spares  mix  for  ORUs  A  and  B  to 
4  and  1,  respectively,  you  can  improve  the  station  availability  (from  90  percent  to 
91  percent)  and  reduce  cost  (ffom  $13  to  $9).  This  example  is  a  simplification  of  how 
the  M-SPARE  model  forecasts  spares  requirements.  Basically,  M-SPARE  sets 
priorities  for  spares  and  selects  the  spares  that  will  improve  the  station  availability 
the  most  per  unit  cost. 

To  prove  our  point,  we  evaluated  a  data  base  with  50  ORUs  using  the  first 
approach  and  selected  spares  so  that  each  ORU’s  performance  probability  would  be 
0.95  or  more.  This  procedure  resulted  in  an  expenditure  of  $106,840  and  station 
availability  of  approximately  25  percent.  For  the  same  $106,840,  M-SPARE  selected 
an  optimal  spares  list  that  produced  a  station  availability  of  73  percent,  almost  three 
times  greater  than  the  traditional  approach.  In  Chapter  7,  we  discuss  how  that 
analysis  can  be  duplicated. 

A  DETERMINISTIC  EXAMPLE 

To  help  define  and  explain  the  M-SPARE  methodology,  let’s  discuss  the  spares 
and  funding  estimates  for  a  simple  example  with  a  deterministic,  constant 
ORU  failure  rate.  Consider  one  ORU  with  a  180-day  logistics  cycle,  one  resupply 
flight  at  the  beginning  of  the  year  and  one  in  the  middle,  four  failures  every  logistics 
cycle,  a  launch  date  of  October  1995  (the  beginning  of  FY96),  and  a  constant  failure 
rate. 


If  this  ORU  is  not  reparable,  then  our  spares  requirement  model  is  simple.  For 
FY96,  the  ORU  needs  4  spares  pre-positioned  on  orbit  on  Day  1  of  the  year  to  replace 
the  4  failures  over  the  course  of  the  first  logistics  cycle  and  then  4  more  ready  for  the 
mid-year  launch  to  cover  the  second  logistics  cycle.  That  sums  to  a  spares 
requirement  of  8  for  the  entire  year.  The  cumulative  spares  requirements  increases 
to  12  in  the  beginning  of  FY97  and  then  16  in  the  middle  ofFY97.  Thus,  for  the 
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nonreparable  example  item,  the  “gross”  spares  requirement  at  launch  equals  the 
cumulative  failures  (previous  failmes  plus  the  expected  failures  in  the  next  cycle) 
shown  in  Row  2  of  Table  l-2a. 


TABLE  1-2a 

SPARES  REQUIREMENTS 
(DETERMINISTIC  FAILURES) 


Logistics 

FY96 

FY97 

FY98 

FY99 

cyde 

D 

2 

3 

n 

5 

D 

D 

D 

Failures 

1 

■ 

■ 

■ 

4 

4 

4 

n 

4 

Cumulative  failures 

2 

H 

8 

12 

16 

20 

24 

H 

32 

However,  if  we  assume  that  the  broken  ORU  is  reparable  75  percent  of  the  time, 
the  generated  repairs  eventually  produce  serviceable  spares  to  replace  some  of  the 
failed  ORUs  and  slow  the  growth  of  the  gross  requirement.  In  our  example,  ORUs  do 
not  start  entering  the  repair  process  until  the  second  shuttle  flight  returns  with 
broken  ORUs  from  the  first  logistics  cycle.  We  assume  the  original  equipment 
manufacturer  (OEM)  requires  145  days  to  repair  them  so  they  are  available  by  the 
end  of  the  year.  Thus,  the  OEM  repairs  three  ORUs  (75  percent  repair  rate  times  four 
broken  ORUs)  in  time  for  the  third  shuttle  launch.  From  then  on,  the  OEM  generates 
an  additional  three  repairs  each  logistics  cycle  (Row  3  of  Table  l-2b). 

TABLE  1-2b 

SPARES  REQUIREMENTS 
(DETERMINISTIC  FAILURES) 


logistics 

cyde 

Row 

FY96 

FY97 

FY98 

FY99 

1 

2 

3 

n 

S 

D 

D 

n 

Failures 

1 

4 

■ 

4 

4 

4 

4 

4 

4 

Cumulative  failures 

2 

4 

D 

12 

16 

20 

24 

28 

32 

Cumulative  repairs 

3 

0 

3 

6 

9 

12 

15 

18 

Requirements 

4 

4 

8 

9 

10 

11 

12 

13 

14 

Grots  requirements/year 

5 

H 

10 

12 

14 

Net  requirements/year 

6 

y 

2 

2 

2 
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We  can  now  calculate  spares  requirements  for  this  reparable  ORU  by 
subtracting  cumulative  repairs  from  cumulative  failures  (i.e.,  Row  2  —  Row  3  =  Row 
4  in  Table  l-2b).  To  calculate  the  maximum  gross  spares  requirements  in  the  year,  we 
use  the  requirements  for  the  second  logistics  cycle  (see  Row  5  of  Table  l-2b).  The  net 
spares  requirements  for  any  year  is  the  increase  in  requirements  from  the  previous 
year  (see  Row  6  of  Table  l-2b).  Alter  the  transition  year,  FY96,  the  net  spares  equals 
the  condemnations  per  year. 

We  next  spread  the  spares  price  (net  spares  times  unit  price)  across  the 
procurement  lead  time  (PLT),  assumed  to  be  the  2  previous  years.  We  also  assume  we 
incur  60  percent  of  our  costs  in  the  first  year  and  40  percent  of  our  costs  in  the  second 
year  of  the  PLT.  (The  user  can  specify  those  percentages  as  input.)  Thus,  if  we  need 
eight  spares  in  FY96  with  a  unit  price  of  $125,000,  we  spend  $600,000  (eight  times 
$125,000  times  60  percent)  in  FY94  and  $400,000  in  FY95  (see  bottom  of  Table  l-2c). 
We  repeat  that  cost  spread  for  the  other  net  spares  requirements  in  the  next  3  years. 
We  develop  ORU  funding  requirements  {annual  budget  estimates)  by  summing  up  the 
dollars  for  each  fiscal  year.  If  we  follow  this  process  for  all  ORUs  and  for  all 
criticalities,  we  have  our  spares  and  funding  requirements  by  year. 

With  this  simple  example  as  background,  we  can  now  discuss  the  basic 
assumptions  of  the  model.  Later,  we  will  expand  upon  our  example  and  discuss  the 
more  complicated  probabilistic  processes  and  changing  failure  rate  implemented  in 
M-SPARE.  In  such  cases,  M-SPARE  adds  “safety”  margins  of  spares  to  the 
requirements  so  that  the  station  can  meet  unexpected  increases  in  demand. 

BASIC  MODEL  ASSUMPTIONS 

To  estimate  funding  requirements,  we  must  make  some  basic  assumptions. 
Those  assumptions  are  intended  to  accurately  reflect  possible  future  conditions  while 
keeping  the  M-SPARE  model  simple  and  understandable.  Figure  1-3  summarizes 
those  assumptions  for  a  single  model  year  —  FY98. 

Since  the  SSF  budget  process  uses  annual  estimates,  we  need  to  develop  spares 
requirements  on  an  annual  basis.  In  addition,  we  need  sufficient  spares  to  satisfy  the 
year’s  most  demanding  requirement.  For  the  growing  SSF,  the  greatest  number  of 
failures  should  occur  at  the  end  of  the  year  when  SSF  is  at  its  largest  configuration. 
Since  M-SPARE  generates  spares  requirements  for  a  specific  logistics  cycle,  we  nm 
M-SPARE  for  the  last  logistics  cycle  in  the  fiscal  year.  In  that  way,  M-SPARE 
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TABLE  1-2c 


SPARES  REQUIREMENTS 
(DETERMINISTIC  FAILURES) 


Logistics 

FY96 

FY97 

FY99 

cycio 

now 

B 

B 

3 

B 

5 

B 

B 

B' 

Failures 

1 

■ 

1 

1 

1 

4 

4 

t 

1 

4 

4 

Cumulative  failures 

i 

\ 

1 

12 

16 

24 

28 

32 

Cumulative  repairs 

3 

1 

■ 

m 

3 

6 

12 

15 

18 

Requirements 

4 

E 

1 

n 

9 

10 

11 

12 

13 

14 

Gross  requirements/year 

S 

1 

1 

8 

10 

12 

14 

( 

> 

1 

1 

1 

■ 

i 

1 

L 

■ 

1 

Outlays 

($000) 

FY94 

FY95 

FY96 

1 

FY97 

FY9e 

1 

■ 

■ 

ForSSFFY96 

ForSSFFY97 

600 

■ 

■ 

■ 

■ 

1 

■ 

m 

1 

For$SFFY98 

ForSSFFY99 

■ll 

III 

1 

BB 

■ 

1 

■ 

■■ 

B 

1UU  "1 

Annual  budget  estimate 

600 

550 

250 

250 

100 

Outlays 


$$$40% 


Delivery 


Launch 

r 

I  LogCycle 


FY96 


'V' 

PLT 


FY97  J  \ _ Fm _ ) 

Model  spares  requirements 


FIG.  1'3.  OUTLAYS  MEET  FUTURE  SPARES  REQUIREMENTS  FOR  FY98 
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requirements  are  based  upon  the  point  when  the  station  growth  is  the  largest.  [In 
exceptional  cases,  ORU  quantity  may  decline  over  time  (e.g.,  phasing  out  an  ORU)  so 
that  the  timeframe  also  ensures  that  we  do  not  buy  a  spare  we  later  will  not  need.] 
We  assume  that  all  ORU  logistic  cycles  end  at  the  end  of  the  fiscal  year  and  start  a 
logistics  cycle  earlier.  For  instance,  if  an  ORU  has  a  180-day  logistics  cycle,  we 
flMiime  the  last  logistics  cycle  starts  on  the  seventh  month  of  the  fiscal  year;  if  an 
ORU  has  a  135-day  logistics  cycle,  we  assume  the  last  logistics  cycle  starts  on  the 
eighth  month  of  the  fiscal  year.  Eventually,  NASA  might  want  to  input  actual 
log^istics  resupply  flight  schedules  into  M-SPARE,  but  for  now  and  for  a  budget 
model,  we  believe  this  level  of  detail  is  adequate. 

Next,  we  assume  that  spares  deliveries  arrive  at  the  beginning  of  each  fiscal 
year.  That  assumption  forces  all  orders  to  be  placed  a  PLT  earlier  (in  Figure  1-3,  that 
is  at  the  beginning  of  FY96).  We  also  assume  that  outlays  for  the  procurement  occur 
over  the  entire  lead  time  (e.g.,  a  2-year  PLT:  FY96  and  FY97).  The  percent  of  unit 
price  that  occurs  each  PLT  year  (e.g.,  60  percent  in  FY96  and  40  percent  in  FY97)  is 
determined  by  a  user-specified  spread  vector. 

For  two  reasons  we  assume  the  station  receives  all  orders  at  the  beginning  of  a 
fiscal  year.  One  reason  is  to  simplify  the  budget  outlay  calculations.  The  outlays  now 
fall  in  the  same  number  of  fiscal  years  as  the  PLT,  and  we  can  easily  apply  and  track 
the  spread  vector  percentages.  The  more  important  reason  is  to  ensure  dollars  are 
budgeted  and  spares  delivered  in  time  to  meet  all  requirements.  In  practice,  the 
station  does  not  need  all  spares  on  Day  1  of  the  year.  However,  the  station  does  need 
many  spares  early  in  the  year  to  be  loaded  for  the  first  shuttle  launch,  which  is 
assumed  to  occur  at  the  beginning  of  the  year.  Also,  all  spares  must  be  delivered  by 
the  last  shuttle  laimch  of  the  year,  which  occurs  near  the  middle  of  the  year.  The 
same  Figure  1-3  process  repeats  itself  for  each  requirement  year  thereafter. 

Finally,  we  assume  that  the  PLT  includes  the  time  from  when  the  broken 
ORU  is  brought  down  to  the  ground  to  the  time  a  new  one  is  procured  and  is  ready  to 
be  loaded  on  the  shuttle.  That  means  the  PLT  includes  production  time,  adminis¬ 
trative  time,  shuttle  launch  processing  time,  order  and  shipping  time,  and  all  other 
delays  that  may  occur.  Users  can  specify  the  PLT  for  each  ORU  (from  1  to  5  years) 
and  the  corresponding  spread  vector  for  each  year. 
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Eventually,  NASA  might  want  to  modify  those  assumptions.  For  instance, 
when  NASA  actually  orders  spares,  they  will  probably  place  orders  throughout  the 
year  and  run  M-SPARE  at  more  frequent  intervals,  perhaps  even  before  every 
procurement.  That  may  cause  the  spares  requirements  to  fall  in  to  more  than  one 
fiscal  year.  We  believe  that  at  this  early  stage  of  station  development  and  for  the 
aggi  ogate  projections  of  a  budget  model,  more  complex  assumptions  are  unnecessary. 

In  summary,  M-SPARE  includes  a  number  of  key  assumptions: 

•  Gross  spares  requirements  are  calculated  on  an  annual  basis  and  represent 
the  maximum  requirements  for  the  fiscal  year. 

•  Net  spares  requirements  (gross  requirements  minus  assets)  are  delivered  at 
the  beginning  of  the  fiscal  year  and  are  ordered  a  PLT  earlier. 

•  Budgets  are  outlays  that  accrue  over  a  specific  fiscal  year  of  the  PLT. 

•  Those  outlays  are  distributed  to  each  PLT  year  based  upon  a  spread  vector 
that  defines  what  percentage  of  the  ORU  unit  price  is  accrued  in  each  of  the 
PLT  years. 

•  The  PLT  includes  the  time  from  when  the  broken  ORU  is  returned  to  Earth 
until  the  time  a  new  ORU  is  procured  and  loaded  on  the  shuttle. 

•  All  costs  are  assumed  to  be  in  constant  dollars  with  the  baseline  year 
equaling  the  year  of  the  ORU  unit  price. 

•  All  time  units  for  spares  and  funding  requirements  are  fiscal  years  unless 
otherwise  specified. 

USERS  AND  USES 

The  M-SPARE  model  is  being  used  at  all  NASA  SSF  project  offices  and  their 
prime  contractors  and  at  the  Canadian  Space  Agency  to  estimate  SSF  spares 
requirements  (the  other  international  partners  have  also  received  copies  of  the 
model).  Specifically,  M-SPARE  is  used  at  project  offices  in  the  POP  cycle  to  produce 
two  basic  products.  The  first  POP  product  presents  the  spares  and  funding 
requirements  or  what  the  station  ideally  would  like  to  have.  The  user  inputs  yearly 
availability  targets,  and  M-SPARE  generates  spares  requirements  for  the  first  years 
of  the  station’s  life  (e.g.,  FY96  to  FY04)  and  the  corresponding  funding  requirements 
for  the  next  9  fiscal  years  (FY94  to  FY02)  that  meet  those  specified  targets.  That 
method  is  described  in  the  Basic  Model  Assumptions  section  of  this  chapter  and  is 
what  we  term  the  spares  requirements  product. 
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For  the  second  POP  product,  the  user  inputs  the  expected  annual  budgets  for 
the  next  9  fiscal  years,  and  M-SPARE  determines  how  many  spares  NASA  can  buy 
with  these  funds.  We  will  refer  to  those  input  budgets  as  annual  POP  marks  and  the 
output  as  the  spares  constrained  budget  product.  It  is  more  difficult  to  produce  the 
constrained  product.  As  we  will  discuss  in  Chapter  9,  M-SPARE  does  produce  spares 
estimates  based  upon  the  POP  marks. 
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CHAPTER  2 


INSTALLATION  AND  DEMONSTRATION 


In  this  chapter,  we  explain  how  to  install  the  model,  how  to  operate  the  user 
interface,  and  how  to  take  the  model  on  a  quick  test  drive.  This  version  of  M-SPARE 
is  self-contained  so  that  the  user  can  edit  input  files,  set  options,  operate  the  wear 
preprocessor  (see  Chapter  10),  and  run  the  model  all  within  the  M-SPAl^  interface. 

INSTALLATION 

To  install  the  M-SPARE  model,  log  on  to  your  computer.  Insert  our  floppy  disk 
into  your  drive  (our  example  assumes  this  will  be  the  A  drive  but  any  high-densiiy 
5.5  inch  floppy  drive  works).  The  commands  listed  below  make  a  new  directory  called 
SPARE  on  your  hard  disk  drive  (our  example  assumes  this  will  be  the  C  drive,  but 
again  any  hard  drive  works)  and  copy  the  required  files  from  our  floppy  disk  to  the 
new  SPARE  directory.  [Note:  All  characters  enclosed  in  double  quotations  are  the 
commands  you  enter  or  select  from  your  PC  keyboard  usually  followed  by  pressing 
the  “Enter”  key.  You  do  not  need  to  enter  the  quotation  marks  themselves.] 

•  Enter  “A:”  —  the  drive  where  our  floppy  disk  is. 

•  Enter  “INSTALL  C”  to  install  the  model  on  your  C  drive. 

•  Press  any  key  to  complete  installation. 

When  the  installation  is  finished,  you  will  see  a  Disk  Operating  System  (DOS) 
prompt  on  your  screen.  At  that  point,  M-SPARE  and  its  accompanying  interface  are 
installed  and  you  are  ready  to  run  the  model. 

INTERFACE  OPERATION 

Now  that  the  model  is  installed,  we  will  discuss  what  is  necessary  to  rim  the 
model. 

•  If  your  system  is  not  already  in  the  SPARE  directory,  type  “CD\SPARE”  to 
move  there. 

•  Type  “START’  to  enter  the  M-SPARE  interface. 
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Your  computer  screen  now  resembles  Exhibit  2-1,  and  you  can  choose  one  of  five 
choices  displayed  in  the  menu  bar  at  the  top.  [Note:  All  exhibits  (figures  in  a  box)  in 
this  report  represent  information  that  may  appear  on  your  computer  monitor.]  The 
user  can  select  a  menu  choice  in  three  ways.  (1)  use  the  left  or  right  arrow  keys  to 
move  the  highlight  bar  to  the  menu  option  and  then  press  the  “Enter”  key,  (2)  press 
the  highlighted  red  letter  in  each  menu  choice,  or  (3)  click  on  the  option  with  your 
mouse.  The  bottom  line  of  the  interface  reminds  you  to  press  the  fimction  key  “FI”  to 
access  the  menu  or  press  the  “ALT-X”  key  combination  to  terminate  M-SPARE  after 
executing  the  model.  Each  of  the  following  menu  choices  corresponds  to  one  of  the 
steps  required  to  run  M-SPARE  and  analyze  its  results. 


EXHIBIT  2-1.  INTERFACE  MENU 


View 


If  you  select  the  “View”  choice,  a  menu  box  appears  (see  Exhibit  2-2)  and  the 
user  can  select  various  options  to  view  M-SPARE  ORU  inputs  (see  Chapter  5)  and 
outputs  (see  Chapter  8).  The  first  step  in  running  the  model  is  to  examine  the  ORU 
data  base,  MSPAREIN.RI*T,  to  make  sure  the  appropriate  data  exists.  From  this 
point,  you  can  also  examine  the  summary  and  detail  output  report  files 
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(BUDGET.RPT  and  OUT.RPT,  respectively)  once  you  run  the  model.  The  computer 
automatically  stores  the  output  reports  from  your  previous  run  (OLDOUT.RPT  and 
OLDBUD.RPT).  In  general,  the  “View”  choice  allows  the  user  to  access  a  powerful 
commercial  text  editor  called  Vedit.  Vedit  can  view  and  edit  large  files,  examine 
several  files  at  once,  and  perform  a  host  of  other  functions  described  in  the 
accompanjring  Vedit  User’s  Manual.  Once  in  the  editor,  press  the  “FI”  key  to  display 
its  menu  choices.  To  access  only  the  editor,  select  the  “Editor”  option.  If  you  then 
change  your  mind  while  in  the  “View”  menu  box,  and  want  to  step  back  to  the 
previous  menu,  just  press  the  “Esc”  key.  [Note:  If  your  package  does  not  contain  a 
text  editor  or  you  want  to  use  your  own,  copy  your  editor  into  the  SPARE 
subdirectory  and  name  it  Vedit  (i.e.,  Vedit.exe  or  Vedit.com).  MS-DOS  5.0  now  has 
an  editor  that  allows  you  to  access  large  files  so  you  may  want  to  use  that  editor.] 


View  Options  Hear  Run  Exit 


Budget. RPT 

F3 

Out.RPT 

F4 

OldBud.RPT 

F5 

OldOut.RPT 

F6 

MSPAREIN.RPT 

F7 

Editor 

F8 

FI  Menu  ALT-X  Exit 


EXHIBIT  2-2.  VIEW  MENU 


Options 

The  second  step  in  running  the  model  is  to  set  the  basic  model  options.  The 
“Options”  menu  choice  opens  the  options  file  that  provide  a  set  of  key  parameters  that 
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usually  do  not  vary  from  one  model  run  to  the  next.  Chapter  6  describes  how  to 
change  options  and  what  each  options  does. 

Wear 

The  third  step  in  running  the  model  is  to  set  up  and  run  the  wear  preprocessor. 
This  step  is  required  only  if  the  MSPAREIN.RPT  file  under  the  “View”  menu 
contains  ORUs  that  may  wear  out  during  the  model  time  horizon.  If  that  is  the  case, 
the  wear  preprocessor  only  needs  to  be  run  once  or  whenever  a  demand  factor  changes 
in  the  MSPAREIN.RPT  file  or  the  launch  schedule  changes  in  the  OPTIONS.RPT 
file.  The  preprocessor  simulates  an  ORU’s  wear  rate  and  random  failure  rate  and 
then  estimates  an  aggregate  failure  rate  (i.e.,  mean  demand).  That  rate  is 
automatically  used  in  the  spares  calculation.  For  more  information  on  the  operations 
of  the  preprocessor,  see  Chapter  10. 

Run 


Once  you  view  the  input,  check  the  options,  and  execute  the  wear  preprocessor 
(if  necessary),  then  select  the  menu  choice  “Run”  to  execute  the  model  and  calculate 
spares  and  budget  estimates.  Chapter  7  describes  the  user  queries  required  for 
M-SPARE  operation.  After  each  M-SPARE  nm,  the  user  is  returned  to  the  initial 
interface  screen  to  examine  the  results  using  the  “View”  choice  or  rerun  the  model 
using  the  “Run”  choice. 

Exit 


When  you  are  finished  with  M-SPARE  and  the  interface,  select  the  “Exit” 
choice  to  exit  the  interface  and  return  to  DOS. 

QUICK  TEST  DRIVE 

To  present  an  overview  of  the  M-SPARE  operations  and  capabilities,  we  will 
take  you  on  a  test  drive.  We  have  already  set  the  options  and  a  sample  data  base  for 
you.  You  will  need  to  take  about  10  minutes  to  enter  the  inputs  we  specify.  Our  goal 
is  to  determine  spares  requirements  for  the  first  8  years.  The  sample  station  is  a 
single  system,  the  electric  power  system  (EPS)  with  only  Criticality  Code  1  ORUs.  In 
Chapter  7,  we  discuss  in  detail  the  meaning  of  the  queries  and  model  plots.  For  now, 
we  merely  present  an  overview  of  the  model  operation. 
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To  begin,  make  sure  you  are  in  the  model  interface.  If  you  have  questions,  see 
the  interface  operation  section  near  the  beginning  of  this  chapter.  Enter  “R”  to  run 
the  M>SPARE  model.  The  model  flashes  the  M-SPARE  title  page  and  then  asks  you 
to  select  a  criticality  code.  Enter  “1”  for  Criticality  Code  1.  Next,  the  model  will  ask 
you  to  enter  information  year  by  year. 

First  Model  Year:  FY98 

Enter  “R”  to  run  the  first  model  year  and  “G”  to  select  the  Ground-Stock-Only 
option  firom  the  Run  menu.  This  reflects  the  fact  that  there  will  be  no  on-orbit  spares 
storage.  Once  in  the  Ground-Stock-Only  Mode  Dialog,  press  the  “Tab”  key,  then 
press  the  down  arrow  to  select  a  ground  availability  target.  Press  the  “Tab”  key 
again  to  move  to  the  next  query  and  enter  a  “95”.  Then,  press  the  “Enter”  key  to  run 
M-SPARE  for  FY98.  In  less  than  a  minute,  the  resource- versus-ground  availability 
curve  (see  Exhibit  2-3)  appears  on  the  screen.  Ground  availability  estimates  the 
performance  only  of  the  ground  inventory,  our  current  assumption.  That  is  the 
probability  the  grotmd  inventory  supplies  all  spares  needed  to  replace  the  on-orbit 
failures  from  the  previous  cycle.  As  we  discuss  in  Chapter  4,  it  is  similar  to 
measuring  station  availability  used  when  both  on-orbit  and  ground  inventories  are 
available. 

The  curve  presents  all  possible  ground  availabilities  under  varying  invest¬ 
ments.  The  solid  area  corresponds  to  the  95  percent  availability  target  you  entered 
and  defines  the  initial  spares  list.  It  shows  that  to  reach  95  percent  availability,  we 
require  a  spares  investment  of  about  $95  million.  The  spares  list  associated  with  that 
point  is  stored  in  the  output  file  that  we  discuss  in  Chapter  8.  Press  the  “Enter”  key 
to  remove  the  plot  and  continue. 

Model  Year  2:  FY99 

To  run  the  next  model  year,  FY99,  for  the  same  availability  target,  press 
“Enter”  to  run  the  model  and  “G”  to  select  the  Groimd-Stock-Only  option  from  the 
rim  menu.  Press  “Tab”,  then  press  “Enter”  (no  additional  selection  is  required 
because  the  model  defaults  are  the  inputs  from  the  previous  year).  In  less  than  a 
minute,  the  resource-versus-ground-availability  curve  (see  Exhibit  2-4)  appears  on 
the  screen.  The  new  curve  is  different  from  the  previous  curve.  The  straight  line  part 
of  the  curve,  from  0  investment  to  $95  million,  displays  the  systems  performance  with 
only  last  year’s  spares  investment  (the  starting  asset  position  for  FY99).  The  curve 
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EXHIBIT  2-3.  RESOURCE-VERSUS-eilOUND  AVAILABILITY  CURVE;  FY98 
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from  $95  million  to  $140  million  displays  the  net  requirements  needed  to  reach  a  95 
percent  availability.  In  other  words,  the  curve  illustrates  that  with  the  growth  of  the 
EPS  in  the  current  fiscal  year,  the  previous  spares  inventory  only  brings  the 
predicted  system  availability  up  to  60  percent.  The  system  requires  a  total 
investment  of  about  $140  million  to  reach  a  95  percent  availability  in  FY99. 

Model  Year  3:  FYOO 

In  the  next  model  year,  we  suppose  that  on-orbit  storage  is  available.  Price  and 
weight  of  each  ORU  is  also  considered.  You  press  “R”  to  run  the  model  year  and 
‘‘Enter”  to  select  the  Multiple-Pass:  Orbit  &  Ground  option  (i.e.,  assumes  levels  of 
orbit  and  ground  storage).  Once  in  the  Multiple-Pass-Mode  Dialog,  keep  pressing 
“Tab”  until  you  highlight  the  last  query,  enter  an  Availability  Target  from  0  to  100 
percent,  and  then  type  “95”  and  press  “Enter”  to  start  the  model  run  for  model  year  3. 
The  model  runs  a  number  of  tradeoff  passes  between  price  and  weight  (the  tradeoff 
you  selected).  Each  pass  reduces  the  total  weight  of  the  on-orbit  spares  at  a  related 
price  penalty  (see  Chapter  3  for  more  information). 

After  a  couple  of  minutes,  a  resource-versus  availability  curve  such  as 
Exhibit  2-4  appears  on  the  screen.  It  shows  that  to  reach  95  percent  availability,  we 
need  resources  of  about  $195  million  and  14,000  pounds  (see  the  exhibit’s  second  and 
third  X-axes,  respectively). 

Press  “Enter”  to  display  possible  price-versus-weight  tradeoff  solutions  for  all 
passes  at  a  95  percent  availability  (see  Exhibit  2-5).  The  plot’s  top  left  point  is  the 
minimum  price  solution.  As  you  move  to  the  right,  total  weight  is  reduced  but  at  a 
price  penalty.  The  solution  M-SPARE  automatically  selects  is  near  the  elbow  of  the 
curve.  We  discuss  how  you  can  select  other  solution  points  in  Chapter  7.  Thus, 
M-SPARE  calculates  spares  requirements  based  upon  price  and  weight  and  also 
presents  a  range  of  possible  solutions.  Press  “Enter”  to  remove  the  plot  and  continue. 

Model  Years  4  to  7:  FY01  to  FY05 

The  next  5  model  years  also  assume  on-orbit  storage  and  a  95  percent 
availability.  For  each  year,  enter  the  following  sequence  of  inputs.  Press  “R”  to  run 
the  model.  Press  “Enter”  to  select  the  Multiple-Pass:  Orbit  &  Groimd  option.  Once 
in  the  Multiple-Pass-Mode  Dialog,  press  “Tab”  and  then  “Enter”.  The  model  does  not 
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EXHIBIT  2-5.  ITERATIVE-PRICE-VERSUS-WEIGHT  TRADEOFF  SOLUTIONS;  FYOO 

require  you  to  enter  a  95  percent  availability  because  that  input  did  not  change  from 
the  previous  year. 

As  in  the  analysis  of  FYOO,  the  model  displays  the  resource-versus-availability 
curve  and  the  iterative-price-versus-weight  solutions  curve.  When  you  are  finished 
examining  a  curve,  press  ‘‘Enter”  to  continue. 

Notice  that  in  FY02,  the  resource-versus-availability  curve  takes  an  imusual 
shape.  This  is  because  the  ORU  batteries  in  the  data  base  are  estimated  to  last 
approximately  5  years  before  they  wear  out.  FY02  is  the  fifth  year  of  their  life  and 
many  will  need  to  be  replaced.  The  previous  year’s  spares  bring  the  station 
availability  up  to  only  15  percent.  However,  once  the  system  adds  batteries,  the 
availability  shoots  up. 

After  you  enter  variables  for  FY05,  your  work  is  over.  'The  model  then 
calculates  the  estimates  for  the  budgets  along  with  other  information  and  stores 
them  in  the  appropriate  files  (see  Chapter  8).  The  model  also  produces  a  summary 
plot  for  spares  weight  (sometimes  referred  to  as  upweight  or  upmass)  estimates  (see 
Exhibit  2-6).  The  model  produces  a  host  of  other  summary  tables  stored  in  output 
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EXHIBIT  2-6.  ANNUAL  SPARES  UPWEIGHT  ESTIMATES 

files,  but  displays  weight  information  because  it  presents  a  glimpse  of  M-SPARE’s 
additional  capabilities. 

Exhibit  2-6  summarizes  two  t3rpes  of  spares  weight  for  all  model  years.  The 
solid  line  displays  the  spares  weight  for  all  shuttle  launches  in  a  particular  year. 
Those  launches  allow  astronauts  to  pre-position  spares  in  space  to  replace  anticipated 
failures.  M-SPARE  estimates  that  laimches  to  pre-position  spares  occur  mostly  in 
2  specific  years:  in  FYOO  (the  first  time  on-orbit  storage  volume  becomes  available) 
and  in  FY02  (in  order  to  replace  worn  out  batteries).  Otherwise,  the  on-orbit 
inventory  levels  remain  relatively  constant.  The  other  weight  resource  type  in 
Exhibit  2-6  (dotted  line)  is  the  resupply  weight  of  the  spares.  The  resupply  weight 
estimates  the  movement  of  spares  from  the  ground  to  the  station.  M-SPARE  assumes 
that  shuttles  resupply  SSF  with  spares  that  replenish  on-orbit  inventory  or  replace 
failed  ORUs  if  no  inventory  is  available.  To  estimate  the  resupply  weight,  M-SPARE 
multiplies  an  ORITs  average  number  of  failures  in  a  year  times  its  unit  weight  and 
then  sums  across  all  ORUs  for  all  criticalities.  We  display  resource  types  to  present 
the  complete  picture  of  spares  weight  requirements  (the  combination  of  on-orbit  and 
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resupply  weight).  As  with  budget  constraints,  SSF  must  eventually  meet  weight  and 
volume  constraints  so  M-SPARE  must  also  estimate  those  requirements. 

When  you  are  finished  examining  the  upweight  estimates  press  “Enter”  and 
you  return  to  the  user  interface  discussed  at  the  beginning  of  this  chapter.  You  can 
now  “View”  the  outputs  or  wait  imtil  we  discuss  outputs  in  Chapter  8. 

PC  REQUIREMENTS 

The  model  operates  on  IBM-compatible  PCs  with  about  two  megabyte  of  hard 
disk  storage  and  about  250  kilobytes  of  memory  to  run  50  ORUs.  A  rough  rule  of 
thumb  is  that  every  ORU  above  the  50  will  require  an  additional  half  of  a  kilobyte  of 
memory.  A  PC  with  a  math  coprocessor  runs  the  model  about  10  times  faster  than 
one  without  a  coprocessor. 

The  model  input  and  output  data  are  text  or  ASCII  (American  Standard  Code 
for  Information  Interchange)  flies  so  that  you  can  browse  them  with  your  editor  or 
word  processor.  You  can  avoid  using  the  interface  if  you  prefer  to  view  the  text  files 
this  way.  Just  type  “MSPARE”  to  run  the  model  from  the  C:\SPARE  DOS  prompt. 

The  key  M-SPARE  input  and  output  files  in  your  C:\SPARE  subdirectory  are 
the  following: 

•  MSPARE.EXE  —  the  M-SPARE  model  in  an  executable  form. 

•  MSPAREIN.RPT  —  a  text  file  that  now  contains  sample  input  data  from 
three  station  subsystems  and  about  50  ORUs  and  eventually  will  contain 
your  ORU  data  base. 

•  OPTIONS.RPT  —  the  options  text  file  that  allows  you  to  change  detailed 
model  options  without  recompiling  a  new  executable  file. 

•  BUDGET.RPT  —  a  text  file  that  contains  the  summary  estimates  of  gross 
and  net  spares  and  funding  requirements. 

•  OUT.RPT  —  the  text  output  file  in  which  the  detailed  spares  results  that 
generate  the  summary  results  of  the  BUDGET.RPT  file  are  stored. 

We  describe  the  pertinent  user  files  in  more  detail  in  the  subsequent  chapters  of 
this  guide. 
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CHAPTER  3 


SPARES  PRIORITIZATION  OVERVIEW 


The  heart  of  the  model  is  the  process  that  sets  priorities  for  spares.  That  process 
builds  a  prioritized  “shopping  list”  for  spares  based  upon  each  spare’s  benefit-to-cost 
ratio.  At  the  top  of  the  shopping  list  is  the  spare  that  has  the  greatest  marginal 
benefit  to  station  availability  per  resource  expenditure,  or  the  biggest  “bang  for 
buck.”  Selecting  in  the  order  indicated  on  the  list  3rields  the  maximum  availability 
rate  for  the  resource  expended.  The  optimization  process  assures  that  no  other 
combination  of  spares  will  give  a  higher  availability  for  the  same  resource  expen¬ 
diture  or  the  same  availability  for  a  lower  resource  expenditure.  As  one  moves  down 
the  priority  list  and  adds  spares  to  those  already  selected,  the  station  availability  and 
resource  expenditiire  increases,  always  yielding  an  optimum  mix.  The  entire  selec¬ 
tion  process  creates  the  resource-versus  availability  curve  (see  Exhibit  2-3),  and  each 
spare  selected  creates  a  point  on  that  curve. 

Significantly,  the  model  can  work  on  any  “physical  system”  or  set  of  ORUs.  For 
this  chapter,  we  will  define  the  set  as  the  critical  ORUs  on  the  station.  However,  the 
same  discussion  can  apply  to  the  set  of  critical  ORUs  at  any  level:  distributed  system, 
subsystem,  or  sub-subsystem. 

Another  significant  point  is  that  the  M-SPARE  model  uses  the  benefit-to-cost 
ratio  and  assumes  that  all  ORUs  are  of  equal  importance  —  if  any  ORU  fails,  it  will 
create  the  same  detrimental  impact  on  the  station  as  any  other  ORU.  For  instance, 
the  model  does  not  consider  that  critical  life  support  ORUs  are  more  important  than 
noncritical  lighting  ORUs  in  the  spares  selection  process.  That  means  the  model  can 
only  handle  one  classification  of  ORUs  at  a  time.  Thus,  the  user  has  at  least  three 
sets  of  ORUs  (Criticality  Codes  1,  2,  and  3).  The  model  handles  each  set  separately. 
Another  reason  for  separating  ORU  types  is  that  Criticality  Code  1  spares  are  stored 
on  orbit  and  on  the  ground  while  other  spares  are  stored  only  on  the  ground.  We 
initially  assume  spares  can  be  stored  at  either  location  and  then  we  disciiss  how  the 
model  handles  a  case  in  which  spares  are  stored  on  the  ground  only. 
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In  the  remainder  of  this  chapter,  we  present  an  overview  of  model  methodology 
in  three  sections: 

•  Station  Availability.  We  define  availability  as  the  probability  that  no 
system  is  inoperative  for  lack  of  a  spare  ORU  over  the  logistics  cycle. 

•  Spares  Prioritization  Across  ORUs.  We  define  the  process  for  prioritizing 
the  ORU  spare  that  yields  the  greatest  bang  for  buck  (highest  station 
availability  per  resource  expended). 

•  Multiple  Resource  Optimization.  We  discuss  how  the  model  manages  several 
resources  separately  and  in  combination,  a  feature  that  allows  the  user  to 
balance  conflicting  resource  expenditures. 

STATION  AVAILABILITY 

A  major  advantage  of  the  M-SPARE  methodology  is  that  it  links  the  spares  mix 
directly  to  station  availability.  To  understand  the  spares  selection  process,  one  must 
first  imderstand  how  M-SPARE  derives  station  availability. 

We  assume  the  station  starts  each  logistics  cycle  after  the  shuttle  has 
resupplied  it  with  a  complement  of  spares.  Those  spares  are  intended  to  satisfy 
demands  (replace  failures)  over  the  logistics  cycle  (i.e.,  until  the  next  shuttle  provides 
resupply).  For  the  station  to  be  available  over  the  entire  logistics  cycle,  each  ORU 
must  either  experience  no  failures  or  have  at  least  one  on-orbit  spare  replacement  for 
every  failme.  We  term  the  likelihood  of  that  condition  as  the  ORU  “probability  of  a 
spare  when  needed”  (PSN).  Thus,  assuming  independence  of  failures  across  ORUs: 

station  availability  =  PSN^  (sj  )  >  [Eq.  3-1] 


where 

Si  =  number  of  spares  for  ORUi 
i  —  ORU  index. 

The  ORU  PSN  used  in  M-SPARE  is  related  to  the  standard  ORU  probability  of 
sufficiency  (POS)  measure,  but  additional  factors  are  considered.  Both  consider  the 
length  of  time  a  broken  ORU  spends  in  the  maintenance  process,  the  length  of  the 
logistics  cycle,  and  the  number  of  on-orbit  ORU  failures  during  that  cycle.  However, 
in  M-SPARE,  the  ORU  PSN  includes  the  possibility  of  starting  the  logistics  cycle 
with  fewer  than  the  desired  number  of  on-orbit  spares  because  the  ground  stock  is  not 
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available  at  shuttle  launch.  Further,  M-SPARE  accounts  for  the  different  benefits  of 
spares  stored  on  orbit  and  on  the  ground  —  it  performs  an  optimal  multi-echelon 
tradeoff.  An  on-orbit  spare  has  a  greater  benefit  to  station  availability  because  it  is 
more  accessible;  a  ground  spare  has  lower  resource  expenditure  because  it  imposes  no 
penalties  for  weight  at  shuttle  launch  or  on-orbit-storage-voliune.  We  present  a 
detailed  discussion  of  the  calculation  of  ORU  PSN  and  the  multi-echelon  tradeoff  in 
Chapter  4.  For  now,  we  assume  that  information  is  available. 

Thus,  station  availability  is  an  indication  of  how  well  the  entire  space  station 
performs  its  mission,  given  a  certain  spares  mix.  We  do  not  imply  that  the  model 
produces  an  all-inclusive  view  of  station  availability;  rather,  it  merely  considers 
hardware  (ORU)  failures.  However,  the  station  may  not  be  available  for  other 
reasons  such  as  lack  of  fuel  or  lack  of  crew  time  to  replace  a  failed  ORU  even  if  a  spare 
is  at  hand.  Nevertheless,  the  model  does  capture  the  most  important  factors  required 
to  estimate  spares.  [M-SPARE  may  be  linked  with  other  models  such  as  Simulation 
of  Manned  Space  Station  Logistics  Support  (SIMSYLS)  or  Reliability  and 
Maintainability  Assessment  Tool  (RMAT)  to  estimate  impacts  of  those  other  factors.] 

SPARES  PRIORITIZATION  ACROSS  ORUs 

Marginal  Benefit-to-Cost  Ratio 

The  first  step  required  to  develop  our  shopping  list  of  spares  is  to  determine  the 
bang-for-buck  measure  (i.e.,  the  marginal  benefit-to-station  availability  divided  by 
unit  resource  expenditure)  for  each  ORU  spare.  Let  us  now  discuss  the  steps 
necessary  to  develop  the  methodology.  Appendix  A  provides  mathematical  proof  that 
our  methodology  produces  an  optimum  solution. 

The  methodology  objective  is  to  maximize  the  availability  in  Equation  3-1 
subject  to  a  constraint  on  spares  investment.  Note  that  Equation  3-1  is  a  product  of 
the  item  decisions,  whereas  spares  investment  is  the  sum  of  costs  on  each  item. 

We  need  to  convert  the  optimization  problem  into  a  sum  of  terms,  so  that  the 
availability  contribution  and  spares  cost  are  additive  across  items.  This  can  be  done 
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by  taking  the  logarithm  of  availability  in  Equation  3-1  since  a  function  and  i  s 
logarithm  achieve  their  maximum  at  the  same  point  (see  Equation  3-2). 


In  {station  availability)  =^y^Jn\ PSNji  Sj )  ] . 

i 


[Eq.  3-2] 


Let  Si  designate  the  optimal  policy  for  each  ORUi  that  produces  the  largest 
availability  for  some  total  investment  in  spares  (e.g.,  si=0  for  all  items  i  when  the 
investment  is  0).  Then,  the  next  item  to  buy  is  that  item  which  gives  the  maximum 
increase  in  the  logarithm  of  availability  per  unit  resource.  This  is  called  marginal 
analysis  and  is  generalized  with  the  following  equation; 


marginal  benefit^  (ai-l-l)]  — /nj^PS^Vj 

unit  resourcei  unit  resource^ 


[Eq.  3-3] 


Example  of  the  Prioritization  Process 

To  explain  the  prioritization  process,  we  use  a  simple  example  for  a  few  ORUs 
and  assume  pi  ice  (dollars)  is  the  resource  type.  We  start  the  process  by  solving 
Equation  3-2  for  the  station  availability  with  no  resource  expenditures  (e.g.,  si=0  for 
all  items).  In  the  example  given  in  Table  3-1,  that  value  is  equal  to  22.8  percent. 

TABLE  3-1 

EXAMPLE  OF  SPACE  STATION  AVAILABIUTY  COST  CURVE 


Curve 

ORU  spares 
prioritized 
(shopping  list) 

Bang  for  buck: 
marginal  bermfit 

cost 

Unit  resource 
(dollars) 

Total 

resource 

(dollars) 

Space  station 
availability 
(percent) 

0 

22.8 

.... 

1 

39.6 

Filter 

0.554 

1 

2 

45.8 

Filter 

0.146 

1 

7 

79.8 

Valve 

0.111 

5 

10 

• 

• 

• 

82.4 

Sensor 

0.033 

3 

Next,  the  model  checks  all  ORUs  and  chooses  the  one  with  the  largest  marginal 
benefIt-to-cost  ratio  (i.e.,  the  filter  with  a  ratio  of  0.554).  It  then  increases  the  station 
availability  by  the  marginal  benefit  to  39.6  percent  and  increases  the  total  resource 
expenditure  by  the  $1  unit  cost  of  the  filter.  The  selection  of  the  filter  creates  the 
second  point  on  our  curve  (first  two  columns  of  Table  3-1).  Next,  the  model  calculates 
a  new  beneflt-to-cost  ratio  for  the  filter  using  Equation  3-3.  Now  the  marginal 
benefit  is  the  difference  between  obtaining  the  second  and  the  first  spare  (i.e.,  0.146). 
At  that  point,  the  process  is  repeated.  The  model  selects  the  spare  with  the  next 
biggest  beneflt-to-cost  ratio  (again,  the  filter);  increments  the  resource  expenditure 
and  station  availability  to  $2  and  45.8  percent,  respectively;  and  recalculates  a  new 
beneflt-to-cost  ratio  for  the  third  filter.  The  model  continues  to  repeat  that  process 
until  the  space  station  availability  is  close  to  100  percent. 

A  final  feature  of  the  model  is  its  ability  to  generate  the  spares  mix  for  a  user- 
specified  resource  or  availability  target.  The  model  uses  the  resource  target  as  the 
maximum  resource  expenditure  and  the  availability  target  as  the  minimum  station 
performance.  To  generate  the  spares  mix,  the  model  checks  each  point  as  it  processes 
the  curve.  When  it  reaches  the  point  at  which  the  curve  value  first  becomes  greater 
than  the  target  value,  it  stops.  If  the  user  selected  an  availability  target,  the  model 
stores  the  spares  level  for  each  ORU.  If  a  resource  target  is  given,  the  model  goes  to 
the  next  to  last  spare  so  that  it  will  not  exceed  the  resource  target.  The  model  then 
stores  the  spares  list. 

In  our  example,  if  we  want  a  spares  mix  for  an  availability  of  82.4  percent,  the 
model  solution  is  to  select  two  filters,  one  valve,  and  one  sensor.  If  we  want  the  spares 
mix  for  a  resource  target  of  $8,  the  model  solution  is  to  select  two  filters  and  one 
valve.  Notice  that  the  resource  target  ($8)  is  always  greater  than  or  equal  to  the 
model  resource  expenditure  ($7)  because  the  model  buys  complete  spares.  In  general, 
the  model  expenditure  is  at  worst  a  few  percent  less  than  the  target.  The  resolution  is 
accurate  enough  given  the  range  of  uncertainties  for  the  budgets  and  spare  costs.  In 
the  next  section,  we  expand  the  model  resources  from  dollars  to  include  weight  at 
shuttle  launch  and  on-orbit  storage  volume. 

MULTIPLE  RESOURCE  OPTIMIZATION 

So  far  in  our  examples,  the  resource  is  the  unit  price  of  the  ORU.  However,  the 
model  can  handle  unit  weight,  unit  volume,  or  a  combination  of  individual  resources 
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to  establish  the  limiting  resource.  When  a  combination  of  resources  is  used,  the 
model  performs  a  multiple-criteria  optimization  and  can  balance  possible  conflicting 
resource  utilization  of  spares. 

The  value  for  the  unit  resource  in  Equation  3-3  is  estimated  with  the  linear 
combination  shown  in  Equation  3-4  for  on-orbit  spares.  Equation  3-4  assumes  that 
the  user  is  interested  in  price  and  weight  for  shuttle  launching. 

unit reaourcei  =  {coefficients. price ^  ^  +  |^(l  —  coefficient)  X  weighty  j.  [Eq. 3-4] 

If  the  user  wishes  to  produce  a  spares  mix  for  the  minimal  total  cost 
(dollars),  the  model  sets  the  coefficient  to  1  and  ignores  the  weight  of  the  ORU. 
Conversely,  if  the  user  wishes  to  produce  a  spares  mix  for  a  minimal  total  weight,  the 
model  sets  the  coefficient  to  0  and  ignores  the  cost  of  the  ORU.  If  a  combination  of  the 
two  resources  is  desired,  the  model  uses  a  coefficient  between  0  and  1.  As  the 
coefficient  value  changes  over  this  range,  the  relative  importance  of  price  to  weight 
changes  proportionately.  Each  spares  mix  produced  in  this  way  is  optimal  in  the 
sense  that  no  other  mix  with  the  same  or  lesser  total  cost  and  the  same  or  lesser  total 
weight  achieves  the  same  or  greater  availability.  (A  modification  of  the  reasoning  in 
Appendix  A  can  be  used  to  establish  this.)  By  using  the  coefficient,  the  user  can 
perform  multi-criteria  optimization  for  two  resources. 

To  demonstrate  the  multi-criteria  optimization,  we  run  the  model  (in  the 
multiple-pass  mode)  for  11  different  passes  using  our  test  drive  data  base  and  results. 
The  example  is  for  Criticality  Code  1  ORU  only.  The  model  automatically  changes 
the  coefficients  after  each  pass,  producing  a  range  of  coefficients  (1.0,  0.9, . . .  0.2,  0.1, 
0).  For  each  pass,  the  user-specified  target  is  set  to  a  95  percent  availability. 
Exhibit  3-1  displays  the  plot  for  the  11  passes.  The  plot  is  really  composed  of 
11  points  connected  by  a  smooth  line. 

Similar  to  the  resource-versus-availability  curve,  the  plot  in  Exhibit  3-1 
describes  the  range  of  tradeoffs  between  cost  and  weight.  The  user  then  can  deter¬ 
mine  which  tradeoff  is  most  appropriate.  For  instance,  we  can  attain  a  fairly  low-cost 
solution  without  totally  sacrificing  station  weight.  The  point  near  the  elbow  of  the 
curve  in  Exhibit  3-1  offers  that  balance  and  is  the  point  the  model  selected  for  the 
spares  solution.  Increasing  the  minimal  total  cost  of  the  spares  mix  by  1  percent 
(from  $193,306  with  a  coefficient  of  1.0  to  $195,230  with  a  coefficient  of  0.5)  improves 
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EXHIBIT  3-1.  RESOURCE  TRADEOFF  POSSIBILITIES  AT  95  PERCENT  AVAILABILITY 


the  total  weight  of  the  initial  spares  49  percent  (from  26,545  pounds  down  to 
13,556  pounds).  [The  Pass  Solutions  Table  (see  Chapter  8)  presents  the  actual 
numbers  that  generated  Exhibit  3-1.] 

The  model  is  actually  performing  two  types  of  tradeoffs  in  Exhibit  3-1.  One 
tradeoff  is  across  ORUs.  As  the  relative  importance  of  weight  increases,  the  model 
moves  from  selecting  ORUs  with  the  greatest  bang  for  buck  to  selecting  ORUs  with 
the  greatest  bang  for  poimd.  The  other  tradeoff  is  between  on-orbit  and  ground  stock 
for  a  specific  ORU.  When  price  is  the  only  resource  of  concern,  on-orbit  spares  are 
selected  because  they  offer  a  greater  improvement  in  availability  than  groimd  spares. 
As  weight  becomes  more  important,  more  ground  spares  are  selected  because  they 
carry  no  weight  penalty. 

As  we  said  earlier,  each  point  in  Exhibit  3-1  is  an  undominated  solution, 
meaning  that  for  a  point’s  total  cost  and  weight,  no  other  spares  mix  will  produce  a 
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higher  station  availability.  Any  mix  with  higher  station  availability  will  have 
higher  cost,  higher  weight,  or  both. 

In  Exhibit  3-1,  we  showed  a  possible  model  scenario  using  price  and  weight  in 
the  ORU  tradeoff  and  a  \iser  availability  target  of  95  percent.  The  model  can  also 
consider,  in  the  linear  combination  for  unit  resource  (Equation  3-4),  the  addition  of  a 
third  resource  —  volume.  (With  modification,  the  model  could  include  many  more 
resources  such  as  pressurized  or  nonpressurized  weight  and  volume.)  Also,  if  the  user 
has  a  ceiling  for  station  on-orbit  storage  volume,  shuttle  lift  weight,  and  spares 
investment,  the  user  can  constrain  the  spares  mix  to  those  limits.  Chapter  7 
discusses  how  that  expansion  and  the  multiple-pass  mode  in  general  are  imple¬ 
mented. 
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CHAPTER  4 


DETAHJID  ORU  MULTI-ECHELON  METHODOLOGY 


In  this  chapter,  we  discuss  the  model  methodology  at  the  lowest  level,  the  ORU. 
We  start  by  discussing  the  multi-echelon  tradeoff  for  each  successive  spare  (specific¬ 
ally,  the  ORU  PSN  and  unit  resource  used  in  Equation  3-4).  That  tradeoff  deter¬ 
mines  the  number  and  storage  location  of  the  spares  the  model  selects.  We  then 
discuss  some  M-SPARE  ORU  extensions  in  order  to  estimate  most  types  of  station 
spares  requirements.  Specifically,  we  discuss  how  M-SPARE  estimates  spares  for 
various  conditions  or  types  of  ORUs  on  the  station. 

The  first  section  of  this  chapter.  The  ORU  Multi-Echelon  Tradeoff,  is  divided 
into  the  following  subsections: 

•  An  Example  of  the  Maintenance  Process.  We  present  a  deterministic 
example  of  the  maintenance  process  and  how  the  process  affects  the  spares 
on  the  station. 

•  Probability  Distribution  of  Unserviceable  Spares.  We  move  away  from  the 
deterministic  example  and  discuss  how  to  calculate  the  probability 
distribution  for  the  number  of  unserviceable  (broken)  imits  in  the  mainten¬ 
ance  process  at  the  start  of  a  cycle. 

•  Multi-Echelon  OR  U  PSN.  We  describe  how  the  model  estimates  the  ORU 
PSN  given  any  combination  of  on-orbit  and  ground  stock. 

•  Multi-Echelon  Tradeoff.  We  discuss  the  spares  selection  process  between  on- 
orbit  and  ground  stock.  The  multi-echelon  tradeoff  is  similar  to  the 
marginal  analysis  technique  used  across  ORUs. 

The  second  section,  ORU  Extensions,  is  divided  into  the  following  chapter 
subsections: 

•  Replaced  Condemnations.  We  describe  how  M-SPARE  selects  spares  to 
replace  past  condemnations. 

•  Element  Launch  and  Assembly  Impacts.  We  discuss  how  the  model 
incorporates  a  growing  station  as  elements  are  added  and  ORUs  and 
quantities  increase. 
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•  Alternative  ORU  Failure  Patterns.  We  describe  how  we  approximate  differ¬ 
ent  failure  patterns  such  as  wear-related  failures. 

•  ORUs  with  Ground  Spares  Only.  We  discuss  ORUs  whose  spares  are  stored 
on  the  ground  only  and  not  on  orbit. 

THE  ORU  MULTI-ECHELON  TRADEOFF 

The  initial  focus  of  the  multi-echelon  tradeoff  is  the  maintenance  process  that 
determines  the  time  to  replace  or  repair  broken  units.  From  there,  the  model 
determines  the  number  of  broken  units  before  each  shuttle  launch,  given  a  total 
spares  level.  Next,  the  model  determines  the  ORUs  available  (total  minus  broken)  to 
the  station.  Then,  the  model  determines  if  the  available  units  are  adequate  to  cover 
the  ORU  failures  in  the  next  logistics  cycle  (the  ORU  PSN).  Finally,  M-SPARE 
determines  the  best  location  (ground  or  on  orbit)  for  each  successive  spares  level. 
This  is  the  multi-echelon  tradeoff. 

An  Example  of  the  Maintenance  Process 

In  this  subsection,  we  describe  the  maintenance  process  and  how  it  affects  the 
spares  for  the  station.  We  provide  an  example  of  an  ORU  with  a  deterministic, 
constant  failure  rate  for  each  logistics  cycle. 

The  maintenance  process  starts  when  an  ORU  fails  on  the  station.  The  model 
assumes  that  the  ORU  is  removed  and  replaced  (if  there  is  a  spare)  and  the  failed  unit 
is  brought  back  to  Earth  on  the  next  shuttle.  Once  the  ORU  is  on  the  ground,  the 
model  assumes  it  will  face  one  of  the  three  alternative  maintenance  levels:  (1)  the 
Kennedy  Space  Center  (KSC)  will  repair  the  ORU;  (2)  the  prime  contractor  or  OEM 
will  repair  the  ORU;  or  (3)  maintenance  engineers  will  condemn  the  ORU  and  a  new 
one  will  be  procured.  If  the  repaired  ORU  or  the  replacement  unit  is  needed,  it  is  then 
ready  to  be  retiirned  to  the  station  on  the  next  shuttle.  [Note:  M-SPARE  does  not 
consider  delays  from  on-orbit  maintenance  in  its  availability  calculation  because  its 
impacts  on  spares  selection  are  minimal.] 

Figiire  4-1  illustrates  the  deterministic  maintenance  process  over  time  (logis¬ 
tics  cycles  of  180  days)  for  a  hypothetical  ORU.  Four  failures  of  the  ORU  initially 
occur  on  orbit  during  a  cycle.  The  failed  units  are  brought  down  to  Earth  where  none 
are  repaired  at  KSC,  three  spares  (three  quarters  of  the  failures)  are  repaired  at  the 
OEM  in  145  days  (less  than  one  logistics  cycle),  and  one  spare  (a  quarter  of  the 
failures)  is  condemned  and  a  new  spare  procured  in  26  months  (less  than  five  logistics 
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cycles).  The  user  inputs  the  fraction  of  failures  distributed  to  each  maintenance  level 
and  the  time  required  for  maintenance  at  each  level,  and  the  M-SPARE  model 
calculates  the  number  of  cycles  required  for  maintenance  (the  number  of  days  divided 
by  logistics  cycle  length).  The  number  of  maintenance  days  at  each  level  is  the  length 
of  time  a  spare  is  on  the  ground  before  it  is  ready  to  be  returned  to  orbit  on  the 
shuttle.  The  number  of  maintenance  days  includes  time  for  testing,  fault  isolation, 
administration,  transportation,  and  other  times  associated  with  the  maintenance 
process  or  shuttle  requirements. 


Logistics  cycles: 

1 

1 

1 

2 

- 1 - 

3 

- 1 - 

4 

- 1 - 

5 

- 1 - 

6 

1 

7 

Total  unserviceable 
spares  at  start  of  cycle: 

0 

4 

1 

1 

1 

1 

0 

FIG.4>1.  MAINTENANCE  PROCESS 
(Estimating  unserviceable  ORU  spares  overtime) 

Most  inventory  models  assume  continuous  repair  and  resupply  of  spares,  but  an 
on-orbit  inventory  is  different.  When  an  ORU  fails  on  orbit,  it  must  wait  for  a  shuttle 
to  return  it  to  the  ground,  and  after  it  is  repaired  or  replaced  on  the  ground,  the  unit 
must  wait  for  a  shuttle  to  return  it  to  the  station.  The  maintenance  plan  must 
include  those  waiting  times.  That  is  why  our  example  includes  the  time  a  broken 
spare  spends  on-orbit  in  the  first  logistics  cycle.  Furthermore,  whether  the  OEM  can 
fix  a  spare  in  45  days  or  145  days,  the  number  of  logistics  cycles  for  maintenance 
remains  the  same.  Thus,  the  key  reference  for  the  model  is  not  days,  like  other 
inventories,  but  conditions  on  the  ground  at  the  beginning  of  each  cycle  before  the 
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shuttle  launch.  (To  simplify  the  model,  we  assume  that  shuttle  launching  and 
landing  occurs  within  a  day.  The  actual  interval  is  longer  than  one  day,  but  it  is 
relatively  short  when  compared  with  the  entire  length  of  the  logistics  cycle.) 

For  our  example,  the  number  of  unserviceable  (broken)  ORUs  for 
Cycles  1  through  7  are  0,  4,  1,  1,  1,  1,  and  0,  respectively  (see  bottom  row  in 
Figure  4-1).  However,  that  example  only  traces  the  tmserviceable  spares  generated 
from  one  logistics  cycle.  Figure  4-2  depicts  that  same  example  with  failures 
generated  from  many  logistics  cycles  overlaid  on  one  another.  Each  horizontal  row 
above  the  logistics  cycle  line  shows  the  number  of  unserviceable  units  generated  from 
the  same  logistics  cycle.  To  estimate  the  total  number  of  unserviceable  spares  before 
any  shuttle  launch,  we  add  the  column  of  numbers  in  Figure  4-2  to  obtain  the  bottom 
horizontal  box.  After  a  few  cycles  (start  of  cycle  6),  we  reach  steady-state  conditions. 
In  steady  state,  the  unserviceable  imits  have  arisen  from  five  different  cycles:  the 
four  failures  from  the  last  logistics  cycle  (three  will  eventually  enter  repair  and  one 
will  be  replaced)  and  then  one  condemnation  from  two,  three,  four,  and  five  cycles 
earlier  (the  other  failures  from  these  cycle  were  repaired  at  the  OEM). 
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FIG.  4-2.  UNSERVICEABLE  ORU  SPARES  AT  SHUTTLE  LAUNCH 

Once  we  know  the  number  of  unserviceable  spares  at  the  beginning  of  each 
cycle,  we  then  know  the  optimal  spares  mix:  the  total  spares  we  need  and  their 
storage  location.  For  the  sixth  logistics  cycle  (the  sixth  shuttle  laimch),  we  know  that 
eight  \mits  are  unserviceable.  We  also  know  that  for  the  next  cycle,  the  station  will 
experience  four  failures  so  it  needs  the  shuttle  to  lift  an  additional  four  spares.  Thus, 
the  station  requires  a  total  of  12  spares  (8  plus  4)  and  4  of  the  spares  stored  on  orbit. 
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As  discussed  in  Chapter  1,  the  model  estimates  net  spares  requirements  once  a 
year  at  a  shuttle  launch  occurring  one  logistics  cycle  prior  to  the  end  of  the  year.  For 
our  example  with  a  logistics  cycle  of  180  days,  the  shuttle  launch  month  (LM)  is  the 
seventh  month  of  each  fiscal  year. 

Probability  Distribution  of  Unserviceable  Spares 

Station  ORUs  do  not  behave  in  a  deterministic  fashion  as  portrayed  in  our 
example.  Each  part  of  the  process  just  described  has  some  uncertainty  that  we 
approximate  with  a  probability  distribution.  For  now,  we  assume  the  on-orbit 
failures  process  is  random  for  each  ORU  so  that  the  number  of  failures  in  a  logistics 
cycle  is  described  by  a  Poisson  distribution.  (Later,  we  will  discuss  how  to  handle 
ORUs  that  are  not  characterized  by  that  random  process  such  as  items  with 
wear-related  failures.)  The  Poisson  distribution  that  estimates  the  probability  of 
variable  on-orbit  failures  for  an  ORU  in  the  next  logistics  cycle  is 

M(f  X  exp(  -MO) 

p{x\MO}  =  - - ,  [Eq.4-1] 


where 

X  =  0, 1, 2, . . .  failures 

MO  =  mean  number  of  orbit  failures  for  the  next  logistics  cycle 
=  A  X  T  X  QPA 


A  =  mean  failure  rate  [1/MTBF  (days)]  X  duty  cycle 
MTBF  =  mean  time  between  failures 
T  =  length  of  the  logistics  cycle  (days) 

QPA  =  quantity  per  application 

The  model  calculates  that  probability  once  each  fiscal  year  at  the  launch  month.  In 
this  case,  the  mean  number  of  orbit  failures  from  our  previous  example  equals  four. 


Each  on-orbit  failure  from  the  original  Poisson  distribution  pattern  with  mean 
MO  has  a  probability  distribution  for  the  number  of  periods  that  will  be  required  for 
the  maintenance  process.  The  mean  of  that  distribution  is  based  upon  the  user’s 
estimate  of  the  actual  length  of  time  the  unit  will  spend  in  each  maintenance  level 
considering  all  conditions  of  the  maintenance  process.  Those  user  estimates  are 
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independent  of  the  number  or  type  of  ORUs  in  maintenance.  Given  that,  we  compute 
the  probability  distribution  for  the  total  number  of  unserviceable  or  broken,  6,  units 
in  maintenance  on  the  ground  or  “just  failed”  on  orbit. 

At  shuttle  launch,  there  are  failures  from  the  previous  logistics  cycle,  there  are 
the  failures  from  two  cycles  ago  that  are  still  in  maintenance,  there  are  failures  from 
three  cycles  ago  that  are  still  in  maintenance,  etc.  Each  of  those  cycles  has  a  Poisson 
distribution  for  unserviceable  units.  Since  the  failures  occur  in  different  cycles  and 
the  maintenance  times  are  independent,  their  probability  distributions  are  inde¬ 
pendent.!  The  sum  of  Poisson  variables  is  Poisson  with  a  mean  equal  to  the  sum  of 
the  individual  cycle  means.  (That  mean  is  what  we  termed  the  total  unserviceable 
spares  at  launch  in  our  deterministic  example.)  Equation  4-2  gives  the  probability 
distribution  for  the  number  of  unserviceable  units  in  maintenance. 

probability  (b  unserviceablea)  =  p(b  \MB)  >  ^^1 


where 

b  =  0, 1, 2, . . .  unserviceable  spares 

MB  =  mean  number  of  unserviceable  units  at  shuttle  launch. 

Multi-Echelon  ORU  PSN 

Once  the  model  estimates  the  probability  distribution  for  unserviceable  spares 
for  a  particular  ORU,  it  then  estimates  the  working  spares  available  for  the  station 
and  the  ORU  PSN  (probability  of  a  spare  when  needed).  At  a  particular  launch,  the 
model  looks  back  to  determine  the  number  of  unserviceables  and  forward  to  deter¬ 
mine  what  will  fail  on  the  station  in  the  next  cycle.  When  that  is  established,  the 
model  then  calculates  the  PSN  for  each  spares  stock  level,  s,  where  s  equals  0, 1, 2,  3, 
etc.  The  level,  s,  for  the  ORU  is  composed  of  the  orbital  echelon  So  and  the  ground 
echelon  Sg  (this  is  what  we  mean  by  a  multi-echelon  stock  policy).  The  model  first 
determines  which  is  the  best  multi-echelon  stock  policy  (i.e.,  produces  the  highest 


iPalm’s  Theorem  establishes  the  fact  that  if  failures  arise  from  a  Poisson  process  and  under 
certain  other  conditions  satisfied  here,  the  number  of  units  in  resupply  is  also  Poisson  with  a  mean 
equal  to  the  product  of  the  failure  rate  and  the  mean  resupply  time.  For  example,  see  Hadley  and 
Whitin,  Analysia  of  Inventory  Systema,  Englewood  Cliffs,  N  J.;  Prentice-Hall,  1963,  p.204. 
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PSN)  for  each  stock  level.  In  other  words,  for  a  spares  level  of  3,  it  decides  whether 
the  best  policy  would  be  to  store  0, 1, 2,  or  3  spares  on  orbit. 

Table  4-1  presents  a  multi-echelon  example  of  the  model’s  evaluation  process 
for  which  s  equals  3  and  So  equals  2.  We  assume  we  send  up  enough  stock  on  each 
shuttle  to  restore  the  orbital  spares  stock  to  Sq,  if  possible.  Of  course,  on  some 
occasions  we  may  not  be  able  to  restore  the  orbital  spare  stock  to  Sg  because  of  the 
number  of  broken  imits  of  the  ORU.  In  order  to  estimate  the  PSN  for  this  stockage 
policy,  the  model  must  consider  several  possible  combinations.  If  0  or  1  spare  is 
broken,  the  station  can  have  two  spares  on  orbit.  Thus,  enough  spares  are  available 
to  cover  0, 1,  or  2  additional  on-orbit  failures.  If  the  ORU  has  2  broken  spares,  it  can 
have  only  1  spare  on  orbit  and  can  cover  only  0  or  1  additional  failure.  If  all  3  spares 
are  broken  on  the  ground,  no  spares  are  on  orbit  and  that  ORU  can  only  operate 
through  the  entire  logistics  cycle  if  it  experiences  no  failures. 

TABLE  4-1 

MULTI-ECHELON  EVALUATION 


Current  status 

Next  cycle  on  orbit 

Possible 

Spares  on 

Failures 

broken  ORUs 

orbit 

covered 

0 

2 

2,1.0 

1 

2 

2,1.0 

2 

1 

1.0 

3 

0 

0 

Nott:  So=2;s=3. 


If  we  take  each  combination  just  described  and  apply  the  appropriate 
probabilities,  the  result  equals  the  ORU’s  PSN  for  a  given  Sg  and  Sg  isg  =  s  —  Sg)  (see 
Equation  4-3).  The  PSN  is  the  sum  of  the  conditional  probabilities.  Each  conditional 
probability  equals  p(b\MB),  the  probability  an  ORU  is  in  a  specific  state,  times 
p(x\MO),  the  probability  an  ORU  has  adequate  spares.  Those  three  conditional 
probability  terms  in  Equation  4-3  are  depicted  by  the  rows  of  Table  4-1.  In  that  table. 
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the  first  two  horizontal  rows  depict  the  first  term  in  Equation  4-3;  the  next  row,  the 
next  term;  and  the  last  row,  the  last  term. 


PSN{8o,8g)  =  [p{b^8g\MB)  X  p{x^8o\MO)]  [Eq.4-3] 

+  [  p{b=8g+l  \MB)  X  p(xS«o— l|3fO)]  . . . 

+  [  p{b=8g+8o[MB)  X p{x=Q\MO)\  . 

Using  Equation  4-3,  the  model  can  estimate  an  ORU  PSN  for  any  combination 
of  on-orbit  and  ground  stock  for  the  next  logistics  cycle.  Table  4-2  lists  the  PSN  for 
different  spares  stock  combinations  using  our  previous  example  —  with  one  modifi¬ 
cation.  We  assume  a  lower,  more  realistic  average  of  0.4  instead  of  4  on-orbit  failures 
per  cycle.  The  maintenance  fractions  and  maintenance  days  remain  the  same  so  the 
mean  number  of  unserviceable  imits  equals  0.8.  In  general,  an  on-orbit  spare  offers  a 
higher  level  of  protection  (a  greater  PSN)  than  a  ground  spare  because  only  an  on- 
orbit  spare  can  replace  a  broken  ORU  and  keep  a  system  operating.  However,  the 
differences  between  the  PSNs  diminish  as  the  number  of  on-orbit  and  on-ground 
spares  increases. 


TABLE  4-2 

ORU  PSN  FOR  COMBINATIONS  OF  ON-ORBIT  AND  GROUND  SPARES 


So  -  Orbital  stock 

■ 

-  Ground  stock 

0 

1 

2 

3 

•  •  • 

0 

30.1 

54.2 

63.8 

66.4 

1 

66.2 

85.5 

91.9 

93.5 

2 

87.9 

96.3 

98.6 

99.1 

3 

96.6 

99.1 

99.7 

99.9 

4 

99.2 

99.8 

99.9 

99.9 

• 

• 

• 
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Multi-Echelon  Tradeoff 

With  the  capability  to  estimate  the  ORU  PSN  for  any  combination  of  spares,  the 
model  can  then  calculate  the  best  allocation  of  on-orbit  and  ground  spares  for  each 
spares  level.  Before  we  discuss  that  prioritization,  we  have  to  define  the  various 
resources. 


Unit  price  is  a  basic  resource  and  does  not  change  if  the  ORU  is  stored  on  orbit 
or  on  the  ground.  Station  storage  volume  is  another  resource  but  is  only  consumed 
when  spares  are  stored  on  orbit.  The  next  resource  is  the  weight  capacity  of  the 
shuttle  flights  that  transport  the  pre-positioned  spares.  Again,  only  spares  stored  on 
orbit  consume  that  resource.  Though  on-orbit  and  needed  ground  spares  require  a  hft 
into  space,  the  on-orbit  spare  actually  requires  an  additional  lift.  The  on-orbit  spares 
require  a  shuttle  lift  to  pre-position  them  on  orbit  and  a  lift  to  replenish  the  inventory 
after  a  failure.  Ground  spares  only  require  one  lift  to  replace  a  failure. 

The  model  starts  the  multi-echelon  tradeoff  process  by  developing  a  benefit-to- 
iinit  resource  ratio  in  order  to  choose  the  spare  location  with  the  largest  ratio.  The 
process  is  similar  to  the  method  discussed  earlier  for  setting  priorities  for  spares 
across  all  ORUs.  The  next  two  equations  extend  the  general  ratio  equation 
(Equation  3-3)  to  treat  on-orbit  and  ground  spares; 

On-orbit  spares: 

marginal  benefit  Zn[PSiV(so+l,Sy)]  —  //»[PSAr(8o,s^)] 

;  =  ^ - - - .  [Eq.  4-4] 

unit  resource  {coefficient  X  price)  +  [{l— coefficient)  X  weight] 


Ground  spares: 

marginal  benefit  Zn[PSiV(8o,  s^+l)]  —  Zn{PSAZ(8<„«^)] 
unit  resource  {coefficient  X  price) 


[Eq.  4-5] 


Thus,  if  the  user  ignores  an  ORU’s  weight  (i.e.,  makes  the  coefficient  equal  1  for 
all  ORUs),  the  model  will  select  an  on-orbit  spare  over  a  groimd  spare.  That  effect  is 
illustrated  in  Table  4-2,  in  which  the  on-orbit  spare  always  produces  a  higher  PSN 
than  the  ground  spare  for  the  same  unit  cost.  In  Table  4-3,  we  take  the  same 
example,  but  consider  cost  and  weight  equally  (coefficient  =  0.5)  and  assume  the 
ORU  costs  $1.00  and  weighs  one  poimd.  The  multi-echelon  tradeoff  selection  process 
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starts  by  choosing  a  ground  spare  (highest  ratio)  and  ends  up  selecting  four  out  of 
seven  on-orbit  spares.  If  weight  is  given  a  greater  importance  (i.e.,  the  coefficient 
decreases)  the  model  selects  the  ground  spares  with  more  frequency. 

TABLE  4-3 

ORU  MULTI-ECHELON  TRADEOFFS 


Spares  selection 

Resource 
($0.5  0.51b) 

PSN 

Benefit/ 
resource  ratio 

Total 

On  orbit 

Ground 

0 

0 

0 

0 

30.1 

.... 

1 

1 

0.5 

54.2 

1.17562 

2 

1 

1 

1.5 

85.5 

0.45604 

3 

1 

2 

2.0 

91.9 

0.14487 

4 

2 

2 

3.0 

98.6 

0.06982 

5 

3 

2 

4.0 

99.7 

0.01184 

6 

3 

3 

4.5 

99.9 

0.00225 

7 

4 

3 

5.5 

99.9 

0.00088 

The  model  implements  its  methodology  by  first  producing  the  last  column  in 
Table  4-3  for  every  ORU.  Then,  at  each  stage  of  the  selection  process,  it  looks  across 
all  ORUs  and  picks  the  ORU  whose  top  spare  has  the  greatest  benefit/resource  ratio. 
The  model  then  moves  on  down  the  ratio  column  of  the  selected  ORU  and  repeats  the 
process.  The  unit  resource  part  of  Equations  4-4  and  4-5  can  be  further  extended  to 
handle  more  resources  (e.g.,  on-orbit  volume). 

ORU  EXTENSIONS 

In  this  section,  we  will  discuss  some  of  the  model  extensions  that  enable 
M-SPARE  to  estimate  most  of  the  station’s  spares  requirements,  including  the 
following: 

•  Modeling  future  replacement  of  condemnations 

•  Station  growth  as  elements  are  launched  and  assembled 
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•  Alternative  ORU  failure  patterns 

•  An  alternative  spares  storage  strategy. 

Replaced  Condemnations 

The  M-SPARE  methodology  mentioned  above  uses  a  repair  philosophy  to 
estimate  unserviceables.  The  model  assiimes  that  after  a  specified  time,  mainte¬ 
nance  generates  a  serviceable  ORU.  A  condemnation  also  undergoes  a  maintenance 
time,  but  unlike  a  repair,  its  “maintenance”  is  actually  the  procurement  of  a  new 
ORU.  In  this  subsection,  we  discuss  how  M-SPARE  incorporates  a  procurement  for  a 
replaced  condemnation  into  its  general  repair  philosophy. 

To  illustrate  that  point,  we  return  to  our  general  example  in  Chapter  1  and 
compare  it  to  our  example  in  the  previous  section  depicting  the  M-SPARE 
methodology  (both  examples  use  identical  deterministic  failures  rates  and 
maintenance  times  and  are  displayed  in  Table  4-4).  The  general  approach  estimates 
spares  requirements  by  subtracting  cumulative  repairs  from  cumulative  failures. 
The  difference  equals  the  spares  required  to  cover  the  number  of  failures  that  remain 
broken  at  the  beginning  of  a  logistics  cycle  (top  of  Table  4-4).  That  is  similar  to  our 
example  in  the  previous  section  (bottom  of  Table  4-4).  For  that  example,  we  directly 
estimated  the  number  of  unserviceables  (items  that  remain  broken)  at  the  beginning 
of  a  cycle  and  add  that  to  the  orbit  failures  for  the  next  cycle  to  estimate  spares 
requirements.  Notice  that  the  requirements/LC  for  the  general  approach  is  identical 
to  the  gross  requirements/LC  in  our  M-SPARE  methodology,  except  for  FY99.  That 
difference  is  because  M-SPARE  thinks  that  maintenance  process  has  had  enough 
time  to  replace  the  earlier  condemnations.  In  Table  4-4,  those  replaced  condem¬ 
nations  equals  cumulative  condemnations  minus  ORUs  in  procurement. 

The  M-SPARE  model  incorporates  replaced  condemnations  by  decreasing  assets 
from  the  previous  year  by  the  amount  equal  to  the  replaced  condemnations.  To 
calculate  the  assets  for  FY99  (bottom  of  Table  4-4),  M-SPARE  takes  the  previous 
year’s  requirements  (12)  minus  the  replaced  condemnations  in  FY99  (2)  to  obtain  a 
current  asset  level  (10).  Now,  when  the  reduced  assets  are  subtracted  from  gross 
requirements/year,  the  net  requirement  equals  2  (12  —  10).  Thus,  the  net  require¬ 
ment  for  the  M-SPARE  implementation  and  the  general  approach  are  equal  (two 
shaded  rows).  In  that  way,  the  net  and  gross  requirements  reflect  the  desired  spares 
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TABLE  4-4 


SPARES  REQUIREMENTS 
(DETERMINISTIC  FAILURES) 


General  approach: 
Failures/LogCycle 
Cumulative  failures 
Cumulative  repaired 


Requirements/LogCycle 
Req  ui  rements/yea  r 
Previous  assets 


M-SPARE  methodology: 
Next  orbit  failures 
Broken  ORUs 


Gross  requirements/LogCyde 
Broken  ORUs 
ORUs  in  repair 
ORUs  in  procurement 
Cumulative  condemnation 


Replaced  condemnations 
Gross  Requirements/year 
Previous  assets 
Replaced  condemnations 


4 

4 

5 

6 

9 

10 

3 

3 

2 

3 

2 

3 

4 

4 

24 

28 

12 

15 

12 

13 

12 

10 

1111 

4 

4 

8 

8 

12 

12 

3 

3 

5 

5 

5 

6 
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quantities.  The  net  spares  requirements  include  replacements  for  condemnations  so 
that  NASA  can  order  and  budget  for  the  proper  number  of  spares. 

Another  point  is  that  when  the  model  reduces  assets  by  the  number  of  replaced 
condemnations,  it  does  not  reduce  M-SPARE  dollar  values.  For  instance,  the 
accumulated  spares  investment  used  for  the  resomrce-versus-availabiUty  curve  still 
includes  the  cost  to  replace  condemnations.  In  that  way,  spares  investment  and  the 
budget  estimates  are  consistent. 

Element  Launch  and  Assembly  impacts 

The  M-SPARE  model  methodology  also  incorporates  failxire  rates  that  vary  over 
time  due  to  element  launches  or  “mission  builds”  (the  construction  phases  of  the 
space  station).  At  any  point  in  time,  the  M-SPARE  failure  rate  equals  the  ORlTs 
duty  cycle,  multiplied  by  the  quantity  per  application  (QPA),  multiplied  by  the 
logistics  cycle,  and  divided  by  the  mean  time  between  failures  (MTBF).  A  particular 
ORU  may  have  applications  that  are  launched  at  different  times.  With  the  increase 
in  the  number  of  applications  on  the  station,  the  ORUs  total  failure  rate  should 
increase  (the  model  holds  duty  cycle,  logistics  cycle,  and  MTBF  constant  over  time). 
M-SPARE  uses  a  monthly  QPA  profile  to  estimate  changing  failure  rates.  The  model 
generates  a  profile  from  the  element  launch  schedule  (see  Chapter  6,  Model  Options) 
and  from  the  number  of  ORU  applications  on  each  element  (see  Chapter  5,  Model 
ORU  Input  Data). 

Exhibit  4-1  displays  the  key  variables  the  model  uses  to  determine  spares 
requirements  and  expands  on  our  earlier  example  (the  tables  in  that  exhibit 
constitute  the  reports  M-SPARE  generates  —  see  Chapter  8,  Model  Outputs).  The 
example  assiimes  the  MTBF  is  2,160  hours,  the  duty  cycle  is  1,  and  the  QPA  is  2  for 
each  of  3  elements.  The  element  launches  are  in  Month  1  of  FY96,  Month  1  of  FYOO, 
and  Month  7  of  FYOl  (the  top  part  of  the  exhibit).  Next,  the  exhibit  presents  the  total 
QPA  profile  by  month  for  10  years.  Notice  how  the  total  QPA  increases  at  each 
element  laimch  month.  The  middle  part  of  Exhibit  4-1  displays  the  QPA  for  each 
element  and  lists  the  element  launch  schedule  in  calendar  and  fiscal  months  and 
years. 
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Element 

Element  Launch 
#  CalenderiMth 

Schedule  ••••••••• 

Year  j  Fiscal :Mth 

FY 

1 

10 

199S  1 

1996 

2 

10 

1999  1 

2000 

3 

4 

2001  7 

2001 

ORU#  1  EXAMPLE  STATION  ORU  LogCycle^’  180  NOT  a  wear  Item 

QPA  BY  MONTH  (COL),  YEARS  (ROW) 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

1996 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

1997 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

1998 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

1999 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2000 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

2001 

4 

4 

4 

4 

4 

4 

6 

6 

6 

6 

6 

6 

2002 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

2003 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

2004 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

2005 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

Element 

« 

1 

2 

3 

Element 

QPA 

2 

2 

2 

AT 

ORU 

1 

EXAMPLE 

STATION 

ORU 

Model  YR 

Mean  Orbit 

Mean  Broken 

Replace  Condemn. 

VMR 

1996 

4.00 

4.00 

0.00 

1.00 

1997 

4.00 

6.00 

0.00 

1.00 

1998 

4.00 

8.00 

0.00 

1.00 

1999 

4.00 

8.00 

2.00 

1.00 

2000 

8.00 

12.00 

2.00 

1.00 

2001 

12.00 

14.00 

2.00 

1.00 

2002 

12.00 

21.00 

2.00 

1.00 

2003 

12.00 

23.00 

4.00 

1.00 

2004 

12.00 

24.00 

5.00 

1.00 

2005 

12.00 

24.00 

6.00 

1.00 

EXHIBIT  4-1.  EXAMPLE  STATION  ORU 


In  FY96  to  FY99,  the  entries  for  the  mean  on  orbit,  mean  broken,  Eind  replaced 
condemnations  at  the  bottom  of  Exhibit  4-1  matches  our  previous  example  in 
Table  4-4.  In  FYOO,  the  QPA  increases  causing  expected  failures  cmd  other  variables 
to  increase  as  well. 

As  discussed  in  Chapter  1,  the  model  estimates  net  spares  requirements  once 
each  year  at  a  shuttle  launch.  That  launch  occurs  a  logistics  cycle  firom  the  end  of  the 
year.  For  our  example,  with  a  logistics  cycle  of  180  days,  the  shuttle  launch  month 
(LM)  is  the  seventh  month  each  fiscal  year.  At  that  time,  the  model  looks  back  to 
determine  the  number  of  unserviceables  units  and  forward  to  determine  what  is 
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expected  to  fail  on  the  station  in  the  next  cycle.  The  bottom  part  of  Exhibit  4-1 
presents  the  key  M-SPARE  variables  at  the  yearly  launch  month  for  mean  orbit 
failures,  mean  broken  ORUs,  and  replaced  condemnations.  We  will  now  present  the 
equations  for  each  of  these  variables  and  then  present  the  equation  variable 
definitions. 

In  Equation  4-6,  the  model  estimates  mean  broken  (MB),  ORUs  for  each  model 
year  by  summing  the  fraction  of  the  total  failures  that  occurred  for  each  component 
(KSC,  prime/OEM,  and  condemnations)  one  maintenance  time  earlier  (see  Equation 
4-7).  Maintenance  time  equals  a  logistics  cycle  for  broken  ORUs  still  on-orbit  plus 
the  number  of  complete  logistics  cycles  in  the  repair/procurement  time. 

3 

MB{yr)=Y,B„  [Eq.4-6] 

/=l 

LU(yr)— 1 

B/(yr)  =  A  X  F,  X  2I  QPA(m) .  [Eq.  4-7] 

m  =  Uiiiyr)—MiIi 

The  equation  to  estimate  mean  orbit,  MO,  failures  for  the  next  logistic  cycle 
(i.e.,  from  the  launch  month  to  the  end  of  the  fiscal  year)  for  a  given  model  year  is  the 
following: 


lM(yr)+MLC—l 

MCKyr)  =  A  X  ^  QPA(m).  [Eq.  4-8] 

m=LM{yr} 

As  discussed  in  Table  4-4,  the  model  estimates  the  number  of  replaced 
condemnations  by  first  subtracting  the  condemnation  component  of  the  mean  number 
of  broken  ORUs  [BaCyr)]  from  the  total  condemnations  since  the  first  month  of  the 
first  model  year.  That  integer  value  is  the  cumulative  number  of  replaced 
condemnations  [CRC(yr)]  (see  Equation  4-9).  Next,  the  model  takes  the  projected 
difference  in  CRC  for  successive  years  to  obtain  the  incremental  number  of  replaced 
condemnations  [RC(yr)]  for  a  specific  model  year  (see  Equation  4-10). 

I  [Eq.4-9] 

-Bg^r)  I 


CRCiyr) 


A  X  F3X 


lM(yr)  —  l 


QPA{m) 


m  =  l 
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RCiyr)  =  CRC(yr)  -  CRCHyr  -  1), 


[Eq.  4-10] 


where 

A 


m 

QPA(m) 

I 

F 

MM 

NLC 


MLC 


LM(yr) 


yr 

RC 

CRC 


=  mean  orbit  failures  per  month 

duty  cycle  X  720  (hours! months) 

MTdF(hours) 

=  1,2...  (year  X  12)  where  the  year  is  the  number  of  model  years 
the  user  specifies  (see  Chapter  6) 

=  sum  of  all  elements  QPA  launched  by  month  m 

=  maintenance  levels  (1  =KSC,  2= prime/OEM,  3= condemnations) 

=  fraction  of  total  failures  entering  each  maintenance  level 

=  maintenance  months  =  JVLCxAfLC 

=  number  of  logistics  cycles  in  the  entire  maintenance  time 

EigCycle  (day8)+  repair  or  replace  (days)  I 
LogCycle  (days)  J 

=  for  value  in  brackets,  take  the  largest  integer  value,  i.e.,  truncate 

real  number  into  a  integer  value 

=  months  in  a  LogCycle 

_  LogCycle  (days) 

30  (daysimonth) 

=  launch  month,  calculation  point  of  spares  requirements,  assumes 
that  it  is  one  LogCycle  from  end  of  fiscal  year 

=  (yrxl2)-MLC  +  l 

=  model  year 

=  replaced  condemnations 

=  cumulative  replaced  condemnations. 
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Alternative  ORU  Failure  Patterns 

Typically,  component  failures  are  assumed  to  follow  a  Poisson  distribution 
pattern.  However,  certain  ORUs  may  exhibit  different  failure  (demand)  patterns 
that  are  not  typical.  M-SPARE  uses  two  additional  probability  distributions  to 
approximate  the  range  of  possible  demand  patterns.  The  actual  distribution  used  by 
the  model  is  determined  on  the  basis  of  the  variance-to-mean  ratio  (VMR)  of  the 
demand  for  ORUs  and  is  an  input  to  the  model  (see  Chapter  5)  or  determined  by  the 
simulation  (see  Chapter  10).  The  ORU  VMR  is  a  measure  of  demand  uncertainty. 
Larger  VMRs  translate  into  higher  spares  requirements.  In  most  cases,  the  ORU 
VMR  is  assumed  to  be  1  and  the  model  uses  the  Poisson  distribution.  If  the  ORU 
VMR  is  less  than  1,  the  model  uses  the  binomial  distribution  method  to  approximate 
the  demand  pattern.  This  method  is  usually  used  for  wear>related  demands  that  are 
more  predictable  than  the  typical  demand  pattern  for  random  failures.  In  those 
cases,  the  simulation  automatically  calculates  the  VMR.  If  the  ORU  VMR  is  greater 
than  1,  the  model  uses  the  negative  binomial  distribution  method  to  approximate  the 
demand  pattern.  That  is  usually  the  case  for  ORUs  with  suspect  data  quality, 
drifting  demand  levels,  or  greater  demand  uncertainty  than  the  typical  ORU. 

When  the  VMR  is  less  than  or  greater  than  1,  the  model  replaces  the  Poisson 
distribution  assumed  in  Equations  4-1, 4-2,  and  4-3  with  the  appropriate  distribution. 
However,  the  basic  methodology  remains  the  same. 

Table  4-5  is  an  example  of  different  distributions  with  a  mean  demand  of  0.4  but 
a  VMR  of  0.6,  1,  and  3.  The  number  of  spares  required  to  obtain  a  cumulative 
probability  of  0.999  (an  indicator  of  ORU  spares  protection)  equals  1,  3,  and  9, 
respectively.  In  other  words,  when  all  else  is  equal,  the  model  more  spares  to  the 
ORUs  with  greater  demand  imcertainty  (larger  VMRs).  [Note:  Since  the  binomial 
distribution  method  requires  certain  parameters  to  be  integer  values,  the  input  VMR 
is  automatically  adjusted  to  meet  that  requirement.] 

ORUs  with  Ground  Spares  Only 

Next,  we  disciiss  those  ORUs  whose  spares  are  only  stored  on  the  ground,  such 
as  noncritical  ORUs  (Criticality  Code  2  or  3)  or  critical  ORUs  when  on-orbit  storage 
is  not  available.  With  no  on-orbit  spares,  the  ORU  PSN  is  very  low.  It  may  cause  the 
station  availability  to  drop  below  1  percent.  A  more  meaningful  measure  is  the 
probability  that  the  ground  inventory  fully  supplies  spares  needed  to  replace  the 
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TABLE  4-5 


COMPARISON  OF  DEMAND  DISTRIBUTIONS 


Spares 

Binomial 

VMR  =  0.6 

Mean  =  0.4 

Poisson 

VMR  =  1 

Mean  =  0.4 

Negative  binomial 
VMR  =  3 

Mean  =  0.4 

Probability 

Cumulativa 

Probability 

Cumulativa 

Probability 

Cumulativa 

0 

0.60 

0.670 

0.670 

0.803 

0.803 

1 

1.00 

0.268 

0.938 

0.107 

0.910 

2 

■■ 

0.054 

0.992 

0.043 

0.953 

3 

0.007 

0.999 

0.021 

0.974 

4 

0.011 

0.985 

5 

0.991 

6 

0.004 

0.995 

7 

0.002 

0.997 

8 

0.001 

0.998 

9 

■ 

0.001 

0.999 

previous  cycle’s  on-orbit  failures.  We  term  that  ground  availability.  The  equation  for 
ground  availability  (Equation  4-11)  is  similar  to  the  equation  for  station  availability 
(Equation  3-1).  The  difference  is  that  for  ground  availability,  the  on  orbit  component 
of  the  PSN  (Equation  4-3)  drops  out  leaving  only  the  p{b)  distribution  for 
unserviceable  (broken)  units  in  maintenance. 


ground  availability  = 


n 


ORl/. 


[Eq.  4-11] 


Use  of  the  groimd  availability  measure  does  not  affect  the  spares  selection 
process.  The  only  difference  is  that  the  PSN  and  availability  is  strictly  a  measure  of 
ground  performance.  In  Chapter  7,  we  discuss  an  operation  mode  in  which  all  ORU 
spares  are  stored  on  the  ground. 
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CHAPTER  5 


MODEL  ORU  INPUT  DATA 


Initially,  the  most  difficult  part  of  the  model  processing  is  the  creation  of  the 
input  file  (MSPAREIN.RPT).  That  file  defines  all  the  ORUs  and  their  characteristics 
(unit  cost,  demand,  repair  times,  weight,  etc.).  This  input  drives  the  M-SPARE 
model.  If  you  wish  the  model  to  produce  an  optimal  spares  mix  for  your  particular 
distributed  system  or  subsystem,  your  data  base  should  contain  the  ORUs  of  only 
that  group. 

INPUT  FILE  DESCRIPTION 

The  input  file  is  in  an  ASCII  text  format  to  allow  browsing  or  editing  with 
standard  PC  editors.  [Note:  Always  save  input  files  in  an  ASCII  or  print  format.] 
Examples  of  the  data  file  headings  and  a  few  ORUs  from  the  sample  data  base  are 
presented  in  Exhibit  5-1.  The  file  columns  are  divided  into  five  sections.  In  the 
following  subsections,  we  define  the  data  fields  of  each  section,  list  the  type  of  field  in 
parentheses,  and  discuss  how  the  data  are  used  in  the  model. 

Description 

The  data  fields  of  this  section  are  the  following: 

•  NAME  —  a  32-character  ORU  name  (character  field). 

•  PART  NUMBER  —  an  18-character  part  identification  number  (character 
field). 

•  CAGE#  —  a  6-character  number  representing  Commercial  and  Government 
Entity  (CAGE)  codes  or  the  Federal  Supplier  Code  for  Manufacturers 
(FSCM)  (character  field). 

•  CT  —  a  2-character  criticality  code  (e.g.,  IR,  1,  IS,  and  3)  used  in  M-SPARE 
to  segregate  different  types  of  ORUs.  The  model  only  optimizes  one 
criticality  code  at  a  time  and  assumes  all  ORUs  with  the  same  criticality 
have  equal  importance  (character  field). 

•  DIST  SYSTEM  —  a  7-character  distributed  system  name.  The  name  allows 
the  model  to  further  break  dovm  model  outputs  to  a  distributed  system  level. 


5-1 


If  the  data  base  contains  ORUs  for  a  specific  distributed  system  only,  this 
field  can  be  used  to  report  results  at  a  subsystem  level  (character  field). 

The  model  uses  the  name,  part  number,  and  CAGE  number  data  fields  for  reporting 
purposes  only.  Thus,  the  fields  can  contain  whatever  you  need  to  uniquely  identify 
the  ORU  (see  Exhibit  5-1). 

Unit  Resources 

The  data  fields  of  this  section  are  the  following: 

•  PRICE  ($K)  —  the  unit  price  of  the  ORU  in  thousands  of  dollars.  The  model 
assumes  that  all  unit  prices  are  adjusted  to  the  same  baseline  year  (real 
value  >  0). 

e  WEIGHT  (LBS)  —  the  unit  weight  of  the  ORU  in  poimds  (real  value  >  0). 

•  VOLUME  (INCH  —  the  unit  volume  of  the  ORU  in  cubic  inches  (real 
value  >  0). 

Miscellaneous 

The  data  fields  of  this  section  are  the  following: 

e  MIN.SPAR  —  a  value  that  allows  the  user  some  flexibility  in  determining 
how  the  model  selects  spares.  Values  greater  than  0  force  the  model  to  buy 
at  least  the  number  of  spares  specified  (see  Chapter  6  for  information  on 
alternative  ways  of  setting  starting  asset  levels).  (Integer  value  s  0.) 

•  P/U  1/0  —  a  value  of  0,  1,  or  2  allows  the  user  to  specify  whether  the  ORU 
requires  an  unpressurized,  pressurized,  or  either  environment,  respectively 
(integer  value  of  0, 1,  or  2). 

•  PLT  $S  —  a.  value  that  determines  the  dollar  “spread”  vector  used  in 
allocating  budget  dollars  over  PLT.  The  vectors  associated  with  the  PLT  $S 
value  (e.g,,  1,  2,  3 ... )  are  stored  in  the  OPTIONS.RPT  file  (see  Chapter  6). 
For  instance,  a  PLT  $S  value  of  1  may  correspond  to  a  vector  in  the 
OPTIONS.RFT  file  of  0.0,  0.85,  0.10,  and  0.05.  That  vector  implies  that  an 
ORU  with  a  unit  price  of  $100,000  requires  $5,000,  $10,000,  and  $85,000  in 
the  first,  second,  and  third  year  of  PLT  respectively,  and  $0  in  the  delivery 
year  (integer  value  >  0). 

Maintenance  Factors 

The  data  in  this  section  are  further  subdivided  into  two  types  of  fields,  each  type 
having  three  choices  (i.e.,  three  maintenance  levels).  Level  1  represents  activities  at 
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May  3 1,1992  M-SPAR  E  ORU  INPUT  DA 

NOTE:  COSTS  ARE  MOD 


DESCRIPTION 

1 

UNIT  RESOURCES  | 

M 

NAME 

PART  NUMBER 

CAGE#/CT 

DIST 

SYSTEM 

PRICE 

(SK) 

WEIGHT 

(LBS) 

VOLUME 
(INCH  '3) 

MIN  P 

SPR  1 

PARABOLIC  ANTENNA 

12345678901234567 

123456 

1 

1234567 

20B5 

409 

8640 

1 

TRANSMITTER-RECEIVER 

XXXXXXXXXXXXXXX 

YYYYY 

1 

6 

614 

65 

1728 

1 

ANTENNA  CONTROLLER 

XXXXXXXXXXXXXXX 

YYYYY 

1 

6 

375 

51 

1728 

1 

SGS  IE  SWITCH 

XXXXXXXXXXXXXXX 

YYYYY 

1 

6 

128 

25 

27 

■  1 

HIGH  RATE  MODEM 

XXXXXXXXXXXXXXX 

YYYYY 

1 

6 

1125 

37 

2280 

1 

HIGH  RATE  FRAME  MUX 

XXXXXXXXXXXXXXX 

YYYYY 

1 

6 

1875 

92 

3420 

1 

BASEBAND  SIGNAL  PROC 

XXXXXXXXXXXXXXX 

YYYYY 

1 

6 

1050 

77 

3420 

1 

VIDEO  BASEBAND  PROCE 

XXXXXXXXXXXXXXX 

YYYYY 

1 

6 

242 

59 

2280 

1 

lEA  STRUCTURE  A 

XXXXXXXXXXXXXXX 

YYYYY 

1 

12 

1517 

25 

4385550 

1 

lEA  TRANSITION 

XXXXXXXXXXXXXXX 

YYYYY 

3 

12 

35 

32 

864 

0 

lEAELECJUNCTl 

XXXXXXXXXXXXXXX 

YYYYY 

3 

12 

49 

42 

1728 

0 

TCS  DEPLOY  RADI 

XXXXXXXXXXXXXXX 

YYYYY 

3 

12 

1046 

658 

491400 

0 

TCS  UTL  PLATT1 

XXXXXXXXXXXXXXX 

YYYYY 

3 

12 

180 

334 

1728 

0 

TCS  UTL  PLAT  T2 

XXXXXXXXXXXXXXX 

YYYYY 

3 

12 

180 

299 

1728 

0 

EXHIBIT  5-1.  EXAMPLE  OF 


1 


INPUT  DATA 
ARE  MODIFIED 


(KSC=1,  OEM  =  2,  CONDEMN  =  3) 

MISC _ I _ M  Al  NTEN  ANCJ_FAaORS_  _J _ DEJMAND  f  Ar[OR_S 


MIN 

SPR 

P/U 

I/O 

PIT 

$S 

DAYS 

1  2 

Mths 

3 

FRACTION 

1  2 

Log 

3  Cyc 

VMR 

CYCLE 

LIFE 

(YR) 

MTBF(HR) 
PER  UNIT 

1 

2 

QPA  by  FY 
3  4 

5 

6 

7 

1 

1 

1 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

68215 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

18169 

2 

4 

4 

4 

4 

4 

4 

1 

1 

1 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

91387 

2 

4 

4 

4 

4 

4 

4 

1 

1 

1 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

113454 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

55071 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

18847 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

13207 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

1  135 

1 

1 

30 

38000 

1 

2 

2 

2 

2 

2 

2 

1 

1 

2 

0 

160 

8 

0 

.9 

1  135 

1 

1 

30 

525600 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

260610 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

,1  135 

1 

1 

30 

164250 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

42340 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

45260 

4 

8 

8 

8 

8 

8 

8 

0 

1 

2 

0 

160 

8 

0 

.9 

.1  135 

1 

1 

30 

49640 

12 

24 

24 

24 

24 

24 

24 

1PLE  OF  ORU  DATA  BASE 


the  repair  facilities  of  KSC,  Level  2  represents  activities  at  the  prime  contractor  or 
OEM,  and  Level  3  represents  condemnation  of  an  ORU  and  its  replacement. 

For  each  level,  the  file  contains  DAYS  or  months  (Mths)  fields  that  specify  the 
time  required  to  repair  or  replace  an  ORU  and  FRACTION  Helds  that  specify  the 
expected  fraction  of  ORUs  entering  the  level.  The  sum  of  the  fractions  for  the  three 
levels  should  equal  1.  If  an  ORU  has  no  repair  at  a  level,  enter  “0”  for  its  fraction. 
The  specific  fields  are  the  following: 

•  DAYS  1  —  the  repair  time  in  days  for  ORUs  being  repaired  at  KSC  (real 
value  a:  0). 

•  DAYS  2  —  the  repair  time  in  days  for  ORUs  being  repaired  at  the  prime 
contractor  or  OEM  (real  value  >  0). 

•  Mths  3  —  the  PLT  in  months  to  replace  a  condemned  ORU  (real  value  >  0). 

•  FRACTION  1  —  the  fraction  of  broken  ORUs  that  are  repaired  at  the  KSC 
(real  value  s  0). 

•  FRACTION  2  —  the  fraction  of  broken  ORUs  that  are  repaired  at  the  prime 
contractor  or  OEM  (real  value  a  0). 

•  FRACTION  3  —  the  fraction  of  broken  ORUs  that  are  condemned  (real 
value  s  0). 

As  discussed  in  Chapter  4,  the  maintenance  times  and  fi’actions  determine  the 
mean  number  of  unserviceable  spares  that  remain  from  one  or  several  previous 
logistics  cycles.  As  KSC  facilities  repair  a  larger  fraction  of  the  broken  ORUs,  the 
shorter  repair  times  will  translate  into  fewer  spares  requirements. 

Demand  Factors 

The  data  fields  of  this  section  are  the  following: 

•  Log  Cyc  —  the  logistics  resupply  cycle  or  time  in  days  between  shuttle 
flights.  That  value  is  used  to  estimate  the  number  of  anticipated  failures 
over  the  next  cycle  and  the  number  of  cycles  required  to  repair  or  replace  an 
unserviceable  item.  While  the  logistics  cycle  can  be  assumed  as  any  number 
of  days  (e.g.,  90, 135,  180, . . . ),  the  value  remains  constant  for  each  model 
run.  The  OPTIONS.RPT  file  also  contains  a  logistics  cycle  delta  value  that 
you  can  use  to  increase  or  decrease  all  ORU  logistics  cycles  (real  value  >  0). 
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•  DUTY  CYCLE  —  the  fraction  of  time  the  ORU  will  operate  over  the  course 
of  a  year.  This  field  might  also  contain  the  product  of  the  duty  cycle  and  a 
demand  multiplier  (real  value  >  0). 

•  VMR  —  the  VMR  measures  demand  uncertainty.  Larger  VMRs  represent 
greater  demand  imcertainty  and  translate  into  higher  spares  requirements 
in  the  model.  A  VMR  of  1.0  reflects  the  assumption  of  a  Poisson  demand 
process.  ORUs  that  wear  out  (have  an  expected  lifetime)  can  have  a  VMR 
less  than  1.0  (see  Chapter  10).  Conversely,  ORUs  whose  data  quality  is 
suspect  can  have  a  VMR  greater  than  1.0  (real  value  >  0). 

•  LIFE  (YR)  —  the  mean  “wear  life”  or  “life  limits”  of  an  ORU  in  years. 
Besides  random  failures  estimated  by  the  MTBF,  the  mean  life  addresses 
failures  caused  by  wear-related  factors.  M-SPARE  estimates  those  time- 
related  failures  with  a  simulation  preprocessor  (see  Chapter  10)  (real  value 
>0). 

•  MTBF  (HR)  PER  UNIT  —  the  MTBF  in  hours  per  unit  or  application  (real 
value  >  0). 

•  QPA  by  FY  —  the  QPA  or  the  total  number  of  a  specific  ORU  type  on  the 
station.  The  QPA  input  is  actually  a  number  of  fields  and  uses  two  possible 
formats:  cumulative  QPA  by  fiscal  year  or  QPA  by  element  based  upon  the 
element  launch  schedule  (mission  build).  If  you  choose  QPA  by  fiscal  year, 
the  first  QPA  column  (QPA  1)  is  the  quantity  assumed  throughout  the  Bscal 
year  for  the  first  model  year  run;  the  next  column  (QPA  2)  is  the  quantity 
assumed  for  the  second  model  year;  and  so  on.  Quantities  of  0  are  accept¬ 
able.  If  you  choose  to  express  QPA  by  element,  then  the  first  column  is  the 
QPA  for  one  element  (e.g..  Laboratory  A),  the  second  column  is  the  QPA  for 
another  element  (Node  1),  and  so  on.  The  model  then  converts  the  QPA  by 
element  into  a  cumulative  QPA  by  fiscal  year  given  the  element  launch 
schedule  defined  in  the  OPTIONS.RPT  file  (see  Chapter  6)  (integer  value 
sO). 

The  model  uses  those  demand  factors  to  obtain  the  demands  per  logistics  cycle. 
Demand  value  is  the  driver  of  the  M-SPARE  model  and  is  derived  with  Equation  4-8. 

Certain  ORUs  have  more  demands  than  actual  failures.  Environmental 
problems,  false  removals,  and  scheduled  maintenance  are  examples  of  additional 
demands  that  require  spares.  Sometimes  those  demands  are  defined  by  a  demand 
multiplier  called  a  K-factor  (e.g.,  K  =  1.2  denotes  that  the  ORU  experiences 
20  percent  more  demands  than  failures).  For  such  ORUs,  the  duty  cycle  field  can 
serve  an  added  purpose  and  contain  the  product  of  the  K-factor  multiplied  by  the  duty 
cycle  fraction. 
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INPUT  FILE  FORMAT 


The  M-SPARE  model  directly  reads  the  MSPAREIN.RPT  file  and,  thus, 
requires  the  data  fields  discussed  to  be  in  a  relatively  loose  data  format.  The  order  of 
the  ORUs  is  not  impor  ant.  Only  the  relative  positions  of  the  data  fields  are 
significant.  Adherence  to  the  following  format  rules  is  necessary  when  creating  an 
ORU  input  file: 

•  The  ORU  data  starts  on  the  line  immediately  after  the  “>”  character.  The 
“  >  ”  character  is  in  the  first  column. 

•  The  “>”  character  also  marks  the  end  of  the  file  and  is  on  the  line 
immediately  after  the  data  for  the  last  ORU.  The  “>”  character  is  in  the 
first  column  of  that  last  line. 

•  Only  the  first  five  character  fields  are  required  in  particular  columns  of  the 
file.  The  model  assumes  each  of  those  fields  meet  the  exact  widths  specified 
in  our  definitions  and  hav  lo  extra  characters  between  them.  Make  sure 
the  first  five  column  width,  are  32, 18,  6,  2,  and  7,  and  start  in  Columns  1, 
33, 51, 57,  and  59,  respectively. 

•  None  of  the  other  numeric  fields  have  to  be  in  specific  columns,  but  the  fields 
must  be  separated  by  one  or  more  blanks.  Real  values  can  have  as  many 
decimal  places  as  desired. 

•  Data  for  all  fields  must  be  included.  If  you  do  not  have  data  for  any 
resource  —  QPA,  duty  cycle,  or  VMR  —  place  a  “1”  in  those  fields  and  place  a 
“0”  in  the  MIN.  SPR  field. 

Table  5-1  summarizes  each  field  type  and  file  format.  Also,  the  model  closely 
links  many  of  the  data  fields  to  the  OPTIONS.RPT  file  discussed  in  Chapter  6. 

INPUT  FILE  SUMMARY 

In  conclusion,  you  have  two  options  for  obtaining  an  input  file.  You  may  use  the 
sample  data  base  file  we  supplied  and  use  an  editor  to  modify  the  ORU  data  to  more 
closely  reflect  your  specific  work  package  information,  or  you  may  create  your  own 
input  file  with  another  software  package,  following  the  format  rules  presented 
earlier.  However,  you  must  make  sure  the  package  output  file  is  in  an  ASCII  format, 
sometimes  referred  to  as  a  report,  text,  or  print  file. 
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TABLE  5-1 


SUMMARY  OF  MSPAREIN.RPT  DATA  BASE  FIELDS 


Header 

Field  type 

Column 

first 

Location 

last 

Comment 

NAME 

32-char. 

1 

32 

PART  NUMBER 

18-char. 

33 

50 

CAGE# 

6-char. 

51 

56 

cr 

2-char. 

57 

58 

Criticality  code 

DIST  SYSTEM 

7-char. 

59 

65 

Distributed  system 

PRICE  ($K) 

Real  >  0 

space 

delimited 

WEIGHT  (LBS) 

Real  >  0 

space 

delimited 

VOLUME  (INCH  *3) 

Real  >  0 

space 

delimited 

MIN.SPR 

Integer  >  0 

space 

delimited 

Minimum  spare 

P/U  1/0 

0,1.2 

space 

delimited 

Pressurized/unpressurized 

PLTSS 

Integer  >  0 

space 

delimited 

Dollar  spread  vector 

DAYS1 

Real  2  0 

space 

delimited 

KSC  repair  time 

DAYS  2 

Real  s  0 

space 

delimited 

OEM/prime  repair  time 

Mths3 

Real  >  0 

space 

delimited 

PLT 

FRAaiON  1 

Real  ^  0 

space 

delimited 

KSC  repair  fraction 

FRACTION  2 

Real  2  0 

space 

delimited 

OEM  repair  fraction 

FRACTION  3 

Real  >  0 

space 

delimited 

Condemnation  fraction 

Log  Cyc 

Real  >  0 

space 

delimited 

Logistics  cycle 

DUTY  CYCLE 

Real  >  0 

space 

delimited 

VMR 

Real  >  0 

space 

delimited 

VMR 

LIFE  (YR) 

Real  >  0 

space 

delimited 

Mean  time  before  ORU  wear- 
out 

MTBF(HR)  PER  UNIT 

Real  >  0 

space 

delimited 

MTBF 

QPA1 

Integer  2  0 

space 

delimited 

QPA2 

Integer  a  0 

space 

delimited 

QPA3 

Integer  ^  0 

space 

delimited 

QPA4 

Integer  2;  0 

space 

delimited 

QPA5 

Integer  >  0 

space 

delimited 

QPA6 

Integer  s  0 

space 

delimited 

QPA7 

Integer  2:  0 

space 

delimited 
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CHAPTER  6 


MODEL  OPTIONS 


The  model  has  several  options  that  are  triggered  from  the  OPTIONS.RPT  file 
(see  Exhibit  6-1).  This  file  is  accessible  through  the  “Options”  choice  on  the  interfigice 
menu.  The  OPTIONS.RPT  file  is  provided  to  set  key  parameters  that  usually  do  not 
vary  from  one  model  run  to  the  next.  That  simplifies  the  user-query  inputs  required 
for  model  operation  (see  Chapter  7).  In  most  cases,  the  user  uses  the  default  values 
specified  below  for  each  option.  However,  the  OPTIONS.RPT  file  allows  you  the 
flexibility  to  test  some  special  cases  by  changing  the  default  values. 

The  user  can  change  any  of  the  option  values  in  the  file  by  selecting  the 
interface  menu  choice  “Options.”  The  interface  then  invokes  the  editor  and  loads  the 
OPTIONS.RPT  file.  We  then  suggest  you  press  the  “Insert”  key  to  turn  off  the  insert 
mode  and  type  over  any  options  you  want  to  change.  The  replaced  values  do  not  have 
to  be  in  exactly  the  same  columns  as  the  originals  but  merely  in  the  general  vicinity. 
Be  careful  not  to  accidently  add  any  lines  because  the  model  will  not  read  the  options 
correctly.  When  you  are  done,  press  “ALT-X”  to  save  the  OPTIONS.RPT  file  and 
return  to  the  interface  menu.  The  definition  and  range  of  global  values  are  discussed 
for  each  of  the  options  in  the  following  sections. 

LOGISTICS  CYCLE  DELTA 

The  M-SPARE  model  allows  the  user  to  change  the  planned  logistics  cycle 
without  editing  the  MSPAREIN.RPT  file.  The  logistics  cycle  delta  allows  a  positive 
or  negative  increment  change  in  the  number  of  days  the  model  applies  to  each  ORU 
logistics  cycle.  Thus,  to  analyze  the  impact  of  slipping  cycles  45  days,  set  the  delta 
to  “45”  and  the  model  automatically  adds  45  days  to  each  ORU’s  cycle.  The  logistics 
cycle  delta  is  included  in  Equations  4-6  through  4-9.  The  option  default  value 
equals  “0”. 

STARTING  SPARES 

The  starting  spare  option  allows  the  user  to  set  the  starting  asset  position  by 
year.  If  the  value  equals  “0”,  the  model  run  year  does  not  consider  previous  year 
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MODEL  OPTIONS  FILE 
(OPTIONS. RPT) 

ssaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaasaaaaaaaaaaasaaassaaaaaaaaasaaaaasaaass 

GLOBAL 

VALUE  DESCRIPTION 


0  -  LOGISTICS  CYCLE  DELTA  in  days:  added  to  all  ORU  logistic  cycle 

1  -  STARTING  SPARES:  run  with  or  without  previous  year's  assets 

0-starting  asset  levels  set  to  0  each  year 

1- starting  level ^previous  year  assets  -  replaced  condemnations. 

2- starting  level ‘MinSpare  for  1st  yr  demand>0,  else  previous  yr. 

10  -  NIMBER  OF  PASSES:  the  number  of  resource  tradeoffs  performed. 

99.0  -  MAXIMUM  AVAILABILITY  (X)  for  the  resource-vs-availabil ity  curve 

1  -  PLOT: 

0  -  produce  no  plots 

1  -  plot  the  resource-vs-availability  curve  and  the 
multiple-pass  curve 

1  TRACE  INFO:  1  -all  tables.  0  -limited  trace  info  in  OUT. RPT 
8  -  NUMBER  OF  MODEL  YEARS  in  SSF  life. 

1998  -  FIRST  MODEL  FY  spares  required  for  building  SSF. 

1994  -  FIRST  BUDGET  FY  that  funding  dollars  are  possible 

0  -  FUNDING  SPLIT:0-single  funding  profile 

1-split  out  development  and  operational  funds 
X  -  BASELINE  FISCAL  YEAR  (not  operational) 

X  -  PRICE  ESCALATOR  PERCENT  (not  operational) 

0  -  LOTUS;  1-output  tables  formatted  for  import  to  LOTUS,  0-do  not 

0  -  QPA  INPUT  FORMAT 

0  -  QPA  is  cumulative  by  FY  with  First  Fiscal  year 
corresponding  to  the  QPA(l)  column  in  MSPAREIN.RPT) 

1  -  QPA  columns  represent  elements(see  Launch  Schedule  below) 

-1  -  DECREMENT  DAYS:  Moves  end  FY  requirements  impact  earlier. 

If  -1  then  decrement  =  ORU  logistics  cycle 
5  -  WEAR  WAKE:  Wake+Model  Year>life  Limit  for  wear  item.default^S 

C  -  DRIVE  LOCATION  for  temporary  files.  Use  RAM  drive  if  possible 
and  if  have  450  bytes  of  memory  per  ORU  available. 

1  -  NUMBER  OF  CRITICALITY  COOES  (e.g.,if  C1.C2,C3  enter  3) 


***  CUMULATIVE  POP  MARKS  by  crit  code  in  constant  $K  for  display  purposes  only)  **** 


CRIT 

FY90 

FY91 

FY92 

FY93 

FY94 

FY95 

FY96 

FY97 

FY98 

FY99 

FYOO 

FYOl 

1st 

0 

0 

0 

0 

0 

0 

5000 

32000 

88000 

156000 

285200 

285200 

2nd 

0 

0 

0 

0 

0 

0 

0 

22222 

44444 

666666 

999200 

999200 

3rd 

0 

0 

0 

0 

0 

0 

0 

33333 

66666 

999990 

385200 

385200 

4th 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

5th 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

SPREAD  VECTORS;  The  Fraction  of  unit  cost  spread  over 
Vector]-  Years  from  Requirement  (i.e..  Delivery) — [ 

0  J-delivery-J - Procurement  Lead  time - J 

0  -1  -2  -3  -4  -5 


>start  - 

1  0 

2  0 

3  0 

4  0 


1  0  0 

0.4  0.6  0 

0.2  0.5  0.3 

0.25  0.25  0.25 


0  0 

0  0 

0  0 

0.25  0 


the 


PLT 


>end  of  spread  vectors 

LAUNCH  SCHEDULE  TABLE  (Row  1  corresponds  to  QPA  col  1  in  the 

Flight  0  I  Calender  |  Launch  MSPAREIN.RPT,  etc.  With  this  format 

ROW  /Element  |  Month  |  Year  M-SPARE  produces  cumulative  QPA  by 

> — start  of  schedule -  fiscal  year. 

1  LabA  12  1996 

2  LabB  3  2000 

3  HabA  6  1999 

> — end  of  launch  schedule - 


EXHIBIT  6-1.  MODEL  OFTIONS.RPT  FILE 
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solutions  and  assumes  that  no  spares  assets  exist.  If  the  value  equals  “1”,  then  each 
successive  year  of  the  model  run  uses  the  previous  year’s  assets  (minus  replaced 
condemnations)  as  a  starting  position  and  then  decides  what  spare  to  select  next.  If 
the  option  value  equals  “2,”  the  model  sets  all  ORU  starting  spares  levels  at  the 
specific  ORU  MIN.  SPR  value  (from  the  input  file  MSPAREIN.RPT)  for  the  first 
model  year  where  ORU  demand  is  greater  than  0.  All  years  after  that  use  the 
previous  year’s  assets.  For  budget  estimates,  the  model  builds  on  the  previous  year’s 
solution  (option  equals  1  or  2).  However,  users  might  want  to  determine  the  spares 
requirements  based  upon  0  starting  assets  each  year  (option  equals  “0”).  'The  default 
option  value  equals  “1”. 

NUMBER  OF  PASSES 

The  M-SPARE  model  is  capable  of  running  a  number  of  passes  for  a  particular 
year  to  help  automate  the  resource  tradeoff  capability.  Exhibit  3-1  displays  the 
iterative  price- versus-weight  solutions  produced  by  the  model.  In  that  example,  the 
maximum  number  of  passes  is  set  to  “10”.  As  that  value  increases,  the  model 
increases  its  range  and  refines  the  resource  tradeoffs.  In  the  Multiple-Pass  Mode 
section  of  Chapter  7,  we  further  describe  how  that  value  is  used.  'The  default  option 
value  equals  “10”. 

MAXIMUM  AVAILABILITY 

This  option  allows  the  user  to  set  the  maximum  availability  of  the  resource- 
versus-availability  curve  (expressed  in  percentages).  Depending  on  the  desired  range 
of  solutions,  you  can  set  the  maximiun  to  “99”  percent  or  “99.99”  percent.  The  default 
option  value  equals  “99”. 

PLOT 


The  plot  value  allows  the  user  to  switch  the  model’s  plotting  function  off  (value 
equals  “0”)  or  on  (value  equals  “1”).  If  the  plot  value  is  on,  the  model  plots  the 
resource-versus-availability  curve  and  if  applicable,  the  multiple-pass  ciurve.  The 
default  option  value  equals  “1”. 

Hard  copies  of  any  plot  can  only  be  made  when  the  plot  is  on  your  monitor 
screen.  If  you  have  an  Hewlett-Packard  (HP)  laser  printer,  press  the  “Space”  bar  or 
type  a  label  and  then  press  “Enter”  to  make  a  hard  copy.  If  you  have  an  Epson 
printer,  press  the  “Print  Screen”  key  to  make  a  hard  copy.  [Note:  If  nothing  prints  on 
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your  Epson,  type  the  command  “GRAPHICS”  before  you  start  the  model  or  add  the 
graphics  command  to  your  AUTOEXEC  .BAT  file.]  You  can  type  a  label,  such  as  the 
date  or  number,  on  the  hard  copy  to  distinguish  it  from  other  similar  plots.  To  do 
that,  simply  type  the  label  before  printing.  If  you  only  press  “Enter”,  you  can 
continue  without  printing  the  plot. 

TRACE  INFORMATION 

The  trace  information  option  allows  the  user  to  limit  the  trace  information  or 
output  reports  that  the  model  generates  in  the  OUT.RPT  file.  If  the  user  enters  a 
“l,”the  model  generates  all  output  tables  described  in  Chapter  8.  The  option  is 
useful  for  testing  and  understanding  the  model  using  an  abbreviated  data  base  and 
model  run.  If  the  user  enters  a  “0”,  the  model  removes  the  tables  that  display  QPA, 
the  resource-versus-availability  curve,  and  the  ORU  input  data  table  (see  the  section 
on  Detail  Spares  Requirements  in  Chapter  8  for  a  description  of  those  tables).  The 
default  option  value  of  “0”  reduces  the  output  file  size  by  50  to  100  pages  but  still 
generates  key  spares  solution  tables. 

NUMBER  OF  MODEL  YEARS 

The  number  of  model  years  option  determines  the  number  of  years  to  be  run  on 
the  model  (i.e.,  the  number  of  annual  spares  requirements  forecasts).  That  time 
period  begins  when  the  station  starts  the  assembly  stage  and  ends  near  the  end  of  the 
budget  forecast  (see  Figure  6-1).  The  station  starts  assembly  at  the  first  element 
launch,  which  is  based  upon  your  ORU  data  base  (you  .may  specify  that  value  in  the 
next  option).  The  end  of  the  period  is  the  last  year  that  spares  requirements  impact 
the  budget.  The  last  year  of  the  model  equals  your  last  budget  year  plus  the  number 
of  years  in  your  maximum  spread  vector  (as  described  in  Chapter  5).  Thus,  the 
nmnber  of  model  years  in  Figure  6-1  equals  “9”  (FY96  through  FY04).  The  model 
includes  FY04  because  spares  requirements  still  increase  budget  outlays  in  your  last 
budget  year,  FY02  (assuming  a  maximum  spread  vector  of  2  years). 

FIRST  MODEL  FY 

The  first  model  fiscal  year  determines  what  year  the  model  run  starts.  You 
must  enter  the  fiscal  year  that  your  first  system  is  launched.  Specifically,  that  date 
represents  the  first  fiscal  year  that  any  ORU  in  your  data  base  (MSPAREIN.RPT) 
may  experience  a  failure.  In  Figure  6-1,  it  corresponds  to  “1996”.  The  QPA  option 
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FIG.  6-1.  KEY  INPUT  VARIABLES  IN  OPnONS.RPT  FILE 


that  follows  contains  additional  information.  The  default  value  is  dependent  upon 
your  MSPAREIN.RPT  file  format. 

FIRST  BUDGET  FY 

The  first  budget  fiscal  year  specifies  the  earliest  year  that  outlays  esm  start  for 
any  spares  procurement.  For  instance,  in  Figure  6-1,  we  assume  “1994”  is  the  first 
budget  year.  You  may  want  to  increase  or  decrease  that  year.  The  main  impact  of 
this  option  is  that  the  model  will  not  allow  funding  requirements  to  precede  that  first 
year.  For  instance,  if  the  model  estimates  an  ORU  spme  requirement  in  FY96  and 
the  ORU  spread  vector  is  over  3  years,  any  funds  the  model  would  have  spread  to 
FY93  are  instead  added  to  FY94  (the  first  budget  year).  To  determine  what  funds 
need  to  be  allocated  before  FY94,  set  the  first  year  to  an  earlier  year.  [Note:  You 
cannot  set  the  first  fiscal  year  earlier  than  “1990.”]  Our  current  default  value 
is  “1994”. 
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FUNDING  SPUT 


The  M-SPARE  model  estimates  spares  and  funding  requirements  by  fiscal  year. 
Certain  users  may  require  those  estimates  to  be  broken  down  further  into  two 
different  budget  category  estimates;  development  and  operational  funding  (see 
Chapter  9  for  more  discussion).  If  the  user  needs  that  breakdown,  enter  "1”.  In 
general,  enter  “0”  for  the  default  option. 

BASELINE  FISCAL  YEAR 

Not  operational. 

PRICE  ESCALATOR  PERCENT 

Not  operational. 

LOTUS 

This  option  modifies  the  output  tables  so  that  the  user  can  move  them  for 
further  manipulation  to  spreadsheet  software  (e.g.,  LOTUS  1-2-3,  QUATTRO  PRO, 
or  Excel).  If  you  enter  a  "1”,  the  model  places  quotes  around  character  fields  in  the 
tables  of  the  BUDGET.RPT  file  and  some  of  the  tables  of  the  OUT.RPT  file.  The 
quotes  allow  certain  spreadsheet  software  to  retrieve  tables  and  automatically 
translate  them  into  spreadsheet  format.  For  LOTUS  1-2-3,  you  “import”  the  file  as 
“numbers”.  For  QUATTRO  PRO,  you  “import”  the  file  using  the  ‘Comma  &  “” 
Delimited’  option  on  the  menu  bar.  For  Excel,  you  open  the  file  as  a  text  file,  set  the 
text  options  delimiter  as  “Custom”  with  double  quotes,  set  the  text  origin  to  DOS,  and 
then  parse  the  number  fields.  If  you  enter  a  “0”  for  the  M-SPARE  LOTUS  option,  the 
model  does  not  print  the  quotes  so  the  table  looks  like  a  standard  document  table. 
The  default  value  for  this  option  equals  “0.” 

QPA  INPUT  FORMAT 

Station  growth,  and  the  corresponding  increase  in  item  failure  rate,  is  reflected 
in  M-SPARE  by  the  ORU  QPA  (quantity  per  application  for  each  ORU)  profile  over 
time  (see  top  of  Exhibit  4-1).  We  currently  have  two  formats  for  that  profile.  If  the 
user  specifies  a  “0”,  the  model  assiimes  the  QPA  is  cumulative  by  fiscal  year  with  the 
first  fiscal  year  corresponding  to  the  QPA(l)  column  in  MSPAREIN.RPT.  If  the  user 
specifies  a  “1”,  the  model  assumes  QPA  columns  represent  elements  and  the  model 
calculates  cumulative  QPA  by  fiscal  year  based  upon  the  la\mch  schedule  (mission 
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builds)  at  the  bottom  of  the  OPTIONS.RPT  file.  Figure  6-2  displays  the  two  options. 
If  the  QPA  is  specified  by  fiscal  year,  it  is  only  adjusted  at  the  beginning  of  each  fiscal 
year.  If  QPA  is  specified  by  launch,  it  is  adjusted  the  month  of  each  launch.  The 
latter  is  more  accurate  but  requires  the  data  base  to  contain  more  detail  (see  the 
Demand  Factors  section  in  Chapter  5  for  more  information).  The  default  value  is 
dependent  upon  yoiu*  MSPAREIN.RPT  file  format. 

Option  0:  QPA  by  fiscal  year 


Cumulative 

QPA 


96  97  98  99  00  01  02  03 

Fiscal  Year 


Option  1:  QPA  by  launch 


Cumulative 

QPA 


element  launch 


Fiscal  Year 


FIG.  6-2  QPA  FORMAT  OPTIONS 


DECREMENT  DAYS 

Decrement  days  determines  when  in  the  fiscal  year  the  last  launch  occurs,  i.e., 
the  logistics  cycle  that  determines  your  spares  requirements  (see  Chapter  1).  The 
model  usually  assumes  the  last  launch  is  a  logistics  cycle  from  the  end  of  the  year  (see 
Figure  6-1).  The  default  value  of  “  —  1”  allows  the  model  to  automatically  change  the 
decrement  to  equal  the  ORU’s  logistics  cycle.  If  you  want  to  experiment  and  change 
the  last  launch  to  the  middle  or  end  of  the  year  enter  a  “180”  or  “0”,  respectively. 
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WEAR  WAKE 


The  wear  wake  helps  determine  which  ORUs  require  the  simulation  pre¬ 
processor  (see  Chapter  10).  For  instance,  if  the  ORU  mean  wear  life  is  19  years,  a 
wear  failure  may  occur  as  early  as  14  years.  The  wear  wake  for  this  case  equals 
“5”  (19  —  14).  Since  the  maximum  number  of  model  years  is  15,  wear-related  failures 
may  occur  within  the  model’s  timeframe  and  M -SPARE  automatically  uses  the 
simulation  preprocessor.  The  user  can  change  the  wear  wake  setting  based  upon  the 
results  of  a  more  detail  simulation  analysis  or  to  force  M-SPARE  to  use  the 
simulation  for  additional  ORUs.  The  default  value  is  “5”  for  this  option. 

DRIVE  LOCATION 

The  drive  location  determines  where  M-SPARE  stores  its  temporary  files.  If 
possible,  you  should  create  a  random  access  memory  (RAM)  drive  in  your  PC’s 
memory.  This  is  a  simulated  disk  drive  that  actually  exists  in  the  PCs  RAM  area.  If 
you  have  the  room  (in  expanded  or  standard  memory),  a  RAM  drive  will  improve  the 
speed  of  the  model  run.  If  you  use  a  RAM  drive,  you  enter  the  letter  of  the  RAM  drive 
for  this  option.  If  you  do  not  have  a  RAM  drive,  you  enter  a  letter  of  the  hard  disk 
drive  (make  sure  the  drive  has  at  least  a  few  megabytes  of  free  storage).  The 
temporary  files  require  about  1  kilobyte  of  memory  per  ORU.  The  default  value  is 
“C”  for  this  option. 

NUMBER  OF  CRITICALITY  CODES 

The  M-SPARE  model  performs  specific  passes  for  each  criticality  code.  If 
MSPAREIN.RPT  file  contains  Criticality  Codes  1,  2,  and  3,  enter  “3”  for  this  value 
and  the  model  estimates  requirements  for  all  codes.  If  you  want  to  nm  the  model  for 
only  one  t3rpe  of  criticality  code,  enter  “1”.  You  can  use  up  to  25  different  criticality 
codes  but  you  must  specify  a  POP  mark  for  each  (see  the  next  option).  The  default  is 
dependent  on  your  MSPAREIN.RPT  file. 

CUMULATIVE  POP  MARKS  TABLE 

The  cumulative  budget  marks  are  fiscal  year  budgets  that  constrain  the  model’s 
spares  estimates.  'The  marks  are  by  criticality  code,  in  constant  dollars,  and  in  the 
same  dollar  year  as  the  unit  prices.  The  marks  help  estimate  the  ‘^rice  guess”  so  that 
M-SPARE  produces  budget  estimates  comparable  to  the  POP  marks  (see  Chapter  9). 
If  you  decide  to  run  the  model  for  fewer  than  three  criticality  codes  (i.e.,  number  of 
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criticality  codes  option  is  less  than  3)  then  put  the  budget  marks  in  the  order  of  your 
next  M-SPARE  run.  For  inst€mce,  to  run  the  model  for  Criticality  Code  2  and 
Criticality  Code  3  only,  enter  “2”  for  number  of  codes  in  the  option  above  and  put 
budget  marks  for  Criticahty  Code  2  in  the  first  row  and  Criticality  Code  3  in  the 
second  row  of  the  marks  matrix.  You  must  make  sure  all  columns  (from  FY90  to 
FYIO)  contain  a  value  even  if  the  earlier  years  equal  “0”  and  the  later  years  are  all 
the  same.  You  can  add  up  to  25  POP  mark  rows.  When  adding  rows,  just  increase  the 
row  number  (first  column)  by  “1”  and  the  number  of  criticality  codes  in  the  previous 
option. 

SPREAD  VECTORS 

The  spread  vector  table  determines  the  fraction  of  unit  cost  that  accrues  from 
the  start  of  the  PLT  until  the  delivery  year.  Each  ORU  in  the  input  data  bases  has  a 
spread  vector  number.  In  Exhibit  6-1,  Vector  2  corresponds  to  a  spread  of  0.0, 0.4,  and 
0.6.  Those  vector  numbers  specify  that  no  costs  accrue  in  the  year  of  delivery, 
40  percent  of  the  ORU’s  unit  price  accrues  in  the  year  right  before  the  ORU  is 
delivered,  and  60  percent  1  year  earlier.  (This  is  the  vector  we  used  in  the  Chapter  1 
example.)  For  an  ORU  with  a  3-year  PLT,  the  user  may  enter  a  vector  similar  to 
Vector  3.  Notice  that  the  vectors  are  reversed:  you  start  by  specifying  the  fraction  for 
the  delivery  year  (e.g.,  FY99)  and  then  move  back  over  the  PLT  1  year  at  a  time  (e.g., 
FY98,  then  FY97 . . . ).  So  far  we  assumed  that  dollar  outlays  for  particular  spares 
requirements  occm:  in  the  previous  fiscal  years  during  the  PLT  (e.g.,  a  spare  in  FY99 
requires  dollar  outlays  in  FY98  and  FY97,  assuming  a  2-year  PLT).  If  you  want  the 
funds  to  accrue  in  the  same  year  as  the  requirement  (e.g.,  a  spare  in  FY99  requires 
dollar  outlays  in  FY99  and  FY98),  you  place  a  value  in  the  first  spread  vector  column 
(labeled  delivery)  and  the  next  column  (labeled  “—1”  year  from  delivery). 
Furthermore,  if  the  full  price  of  the  spare  is  paid  on  delivery,  then  set  the  spread 
vectors  to  “1”  in  the  delivery  year  and  “0”  thereafter.  You  can  add  vectors  by  adding 
similarly  formatted  lines  before  the  end  of  the  data  marker  (“>”).  When  adding 
vectors,  you  must  increase  the  spread  vector  number  (first  column)  by  1. 

LAUNCH  SCHEDULE  TABLE 

If  the  QPA  format  option  equals  “1”,  then  M-SPARE  requires  a  launch  schedule 
(see  bottom  of  Exhibit  6-1).  The  schedule  defines  the  calendar  month  and  year  of  each 
SSF  element  launch  (mission  builds).  M-SPARE  auton  atically  converts  launch  year 
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into  fiscal  year,  since  fiscal  years  are  the  model’s  time  units.  When  an  entered  year 
falls  after  the  last  model  year  (e.g.,  “3000”),  the  element  is  not  used  in  the  model  rim. 
The  Hrst  row  in  the  table  (LabA)  corresponds  to  the  first  QPA  column  in 
MSPAREIN.RPT.  The  model  calculates  cumulative  QPAs  by  month  by  summing 
QPA  quantities  for  all  elements  previously  launched.  In  the  Exhibit  6-1  schedule, 
QPAs  overtime  is  based  upon  launch  times  for  the  Lab  A,  Node  1,  Cupola  1,  and 
Airlock  launches.  The  cumulative  QPA  profile  appears  at  the  bottom  of  Figure  6-2. 
You  can  add  or  delete  element  launches  by  adding  or  deleting  lines  of  the  file  between 
the  data  markers  (“>”).  Just  make  sure  the  added  laimch  dates  have  the  same 
format  as  what  exists  in  your  original  OPTIONS.RPT  file  and  that  the  element  name 
does  not  extend  past  Column  15. 
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CHAPTER  7 


MODEL  OPERATION  AND  ANALYSIS 


This  chapter  discusses  how  to  run  M-SPARE  and  the  various  t3rpes  of  analyses 
it  can  perform.  By  this  point,  we  assume  you  opened  the  M-SPARE  interface  (see 
Chapter  2)  and  developed  the  three  inputs  required  to  run  the  model.  Those  inputs 
are  the  MSPAREIN.RPT  file  that  contains  the  ORU  data  base,  the  OPTIONS.RPT 
file  that  contains  M-SPARE  parameters,  and  the  wear  preprocessor  that  develops 
aggregate  demand  parameters.  Those  inputs  change  relatively  infrequently.  Most  of 
the  parameters  can  be  adjusted  via  the  M-SPARE  query  selection  we  will  now 
discuss. 

The  basic  steps  to  execute  M-SPARE  on  your  PC  are  the  following: 

•  Enter  *‘CD\SPARE”  to  move  to  the  SPARE  directory  if  not  already  there. 

•  Enter  “START”  to  enter  the  M-SPARE  interface. 

•  Enter  “R”  to  run  M-SPARE. 

The  basic  model  operation  is  to  run  one  criticality  code  at  a  time.  Once  a 
criticality  code  is  selected  by  the  user,  the  model  then  steps  through  each  year  of  the 
station’s  life  (see  Figure  1-1).  For  each  year,  it  asks  you  to  enter  some  basic 
parameters  and  then  it  determines  what  spares  this  criticality  requires.  With  each 
new  year,  the  number  and  quantity  of  ORUs  in  the  station  change  as  the  station 
configuration  changes.  Annual  spares  requirements  reflect  these  changes.  The 
number  of  yearly  iterations  depend  upon  the  number  of  years  in  the  budget  projection 
and  is  set  by  the  number  of  model  years  you  specified  in  the  OPTIONS.RPT  file  (see 
Chapter  6).  When  the  model  finishes  calculating  the  yearly  iterations,  it  repeats  the 
process  for  the  next  criticality  code.  When  it  finishes  vrith  all  the  criticality  codes,  it 
then  computes  the  budget  for  all  ORUs  from  all  criticality  codes. 

Exhibit  7-1  is  the  first  query  that  appears  on  your  monitor  when  you  run 
M-SPARE.  It  asks  you  to  select  a  criticality  code.  M-SPARE  develops  spares 
requirements  one  criticality  code  at  a  time.  You  now  enter  a  criticality  code  of  one  or 
two  characters.  If  you  enter  a  single  character  such  as  a  “1”,  the  model  selects  all 
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ORUs  with  a  1,  as  the  first  character  in  its  criticality  code.  That  means  ORUs  with 
1  and  IR  become  the  selected  ORUs  for  the  spares  optimization.  If  you  wish  to  run  a 
subset  of  Criticality  Code  1  separately,  you  enter  two  characters  such  as  “1  ”  or  “IR” 
for  nonredimdant  and  redundant  ORUs.  The  model  is  sensitive  to  upper  and  lower 
case  letters  so  that  a  IR  and  a  Ir  are  not  the  same. 


Enter  Criticality  Code  (1,2,3,1R,2R — ) 

To  combine  Crit  1  &  IR  enter  "1" 

To  separate  Crit  1  &  IR  enter  "IR"  &  "1_"  (add  space) 
Careful,  the  model  is  sensitive  to  super  &  lower  case 
so  a  Ir  and  a  IR  are  different  codes 
1 


EXHIBIT  7-1.  CRITICALITY  CODE  QUERY 

The  screen  shown  in  Exhibit  7-2  appears  next.  This  is  the  monitor  screen  you 
will  return  to  with  each  new  model  year  or  if  you  want  to  start  over.  For  now,  simply 
press  “Enter”  for  run.  A  dialog  box  similar  to  Exhibit  7-3  will  appear. 

Exhibit  7-3  displays  the  five  menu  choices  (top  of  box).  The  text  in  the  bottom 
part  of  the  box  presents  the  status  information  on  the  model  year,  fiscal  year,  and 
criticality  code  for  the  current  model  iteration.  The  menu  choices  succinctly 
summarize  the  capabilities  or  modes  of  M-SPARE.  Each  mode  has  a  specific  purpose 
and  each  is  described  in  a  separate  section  in  this  chapter.  The  modes  are  as  follows: 

•  Multiple-pass  mode  performs  tradeoffs  between  ground  and  on-orbit  storage 
and  between  two  resources.  The  model  performs  multiple  passes  and 
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Run  Exit 


Menu  Ctrl -Break  Exit 


EXHIBIT  7-2.  INITIAL  YEAR  MENU 


Multiple  Pass:  (orbit  &  ground) 

F2 

Single  Pass:  (orbit  &  ground) 

F3 

Ground  Stock  Only 

F4 

Minimum  Spares  Evaluation 

F5 

Global  ORU  POS  Mode 

F6 

Model  Year 

1 

Fiscal  Year 

1998 

Criticality  Code 

1 

EXHIBIT  7-3.  MODEL  RUN  OPTIONS  MENU 
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automatically  varies  the  relative  importance  (the  coefficients)  between 
resources  for  each  pass. 

•  Single-pass  mode  allows  you  to  specify  the  resource  coefficients  in  order  to 
examine  a  specific  pass  solution.  You  may  also  specify  your  own  coefficients 
and  calculate  tradeoffs  between  ground  and  on-orbit  storage. 

•  Ground- stock-only  mode  changes  the  model  orientation  to  handle  those 
ORUs  that  can  only  be  stored  on  the  ground  such  as  noncritical  ORUs. 

•  Minimum  spares  evaluation  mode  (not  operational). 

•  Global  ORU  POS  mode  estimates  the  ground  availability  of  setting  each 
ORU  to  a  user-specified  POS  target. 

In  our  discussion  of  each  of  those  modes  and  their  respective  inputs,  we  start  with  the 
single-pass  mode  and  then  describe  the  other  modes  in  the  order  listed  above.  We 
deal  with  the  single-pass  mode  of  operation  first  because  that  is  the  building  block  for 
generating  more  complex  analyses  such  as  the  multiple-pass  mode. 

To  select  the  single-pass  mode,  you  press  the  “  J,  ”  key  until  the  mode  is 
highlighted  and  then  press  “Enter”  (you  can  also  press  the  bold  or  red  letter  of  the 
mode  “S”  or  select  the  mode  with  your  mouse).  Your  monitor  displays  a  screen 
similar  to  Exhibit  7-4.  Once  you  enter  a  mode  dialog,  pressing  the  “Tab”  key  will 
allow  you  to  step  through  the  queries.  Press  “Enter”  (or  the  “OK”  button)  when  you 
have  answered  all  queries.  If  you  wish  to  go  back  to  a  quer  v  ket  ^  -  ressing  the  “Tab” 
key  to  cycle  through  the  list  again  or  use  a  mouse  to  make  ^  se  . .action.  In  addition, 
the  model  remembers  your  previous  year’s  dialog  selection  and  keeps  them  as  the 
starting  conditions  for  the  current  year.  An  important  point  is  that  even  if  the 
dialogue  is  properly  set  from  the  previous  year,  you  must  press  the  “Tab”  key  before  you 
press  “Enter”  to  begin  execution.  If  you  select  the  wrong  mode,  press  the  “Escape”  key 
or  the  cancel  button  to  start  over  again  and  the  Exhibit  7-2  screen  will  appear  on  your 
monitor.  To  exit  or  abort  an  M-SPARE  run  entirely,  select  “Exit”  from  the  menu  in 
Exhibit  7-1.  Once  the  model  starts  calculating,  you  can  exit  by  pressing  “Ctrl- 
Break”. 

SINGLE-PASS  MODE 

The  M-SPARE  model  requires  two  types  of  station  (system)  inputs:  targets  and 
resource  coefficients.  Targets  are  station  goals  (e.g.,  availability)  that  determine  the 
spares  solution  point  on  the  resource- versus-availability  curve.  Resource  coefficients 
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are  factors  we  have  developed  to  effect  the  model  optimization  process.  Coefficients 
determine  the  relative  importance  of  each  of  the  resources.  The  more  important  a 
resource,  the  more  the  model  conserves  that  resource  expenditure.  M-SPARE 
handles  four  categories  of  targets,  including  (1)  availability  —  the  minimum 
acceptable  station  performance  the  user  wants,  (2)  cumulative  weight  (past  and 
present  model  years)  —  the  maximum  number  of  pounds  allotted  for  spares  on 
shuttle  flights,  (3)  cumulative  price  —  the  total  investment  in  spares,  and 
(4)  cumulative  volume  —  the  maximum  on-orbit  storage  volume  in  cubic  inches.  You 


must  enter  one  to  four  of  the  targets.  If  you  enter  more  than  one  target,  the  model 
stops  when  the  first  value  of  any  of  the  targets  is  met.  That  determines  the  spares 


mix  solution.  If  you  do  not  have  to  or  do  not  want  to  consider  a  target,  enter  “0”.  A 
"0”  automatically  sets  the  target  to  a  maximum  value  for  you. 


Run  Exit 


r  (■I——  SI  ngle-Pass  Mode  Dialog 


Model  Year:  1 

Fiscal  Year:  1998 
Crit  Code:  1 

Enter  Volume  Coefficient  0 

Enter  Price  Coefficient  1 

Enter  Weight  Coefficient  0 

Enter  Cumulative  Volume  Target  in  cubic  inches:  0 

Enter  Cumulative  Price  Target  in  SlOOOs:  0 

Enter  Cumulative  Weight  Target  in  pounds:  0 

Enter  Availability  Target  from  0  to  100  percent:  0 


Tab  Next  Query  Return  OK-Oone 
Tab-Return  OK-Done  Esc  Cancel  Tab  Next  Query 


FI  Menu 


Ctrl -Break  Exit 


EXHIBIT  7-4.  SINGLE-PASS  MODE 


The  model  also  handles  three  resource  coefficients:  price,  weight,  and  volume. 
Equation  7-1  presents  the  linear  combination  of  coefficients  and  resources  used  to 
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estimate  the  on-orbit  unit  resource  for  the  model  (a  slight  modification  to 
Equation  4-4). 


unit resourcci  =  (cp)%Ki  + {cw)LBSi  + (cv)IN"3i,  [Eq.  7-1] 


where 

i  =  ORU  index 

cp  =  price  coefficient 

cw  =  weight  coefficient 

cv  —  volume  coefficient 

$K  =  ORU  unit  price  in  $ 1,000s 

LBS  =  ORU  unit  weight  in  pounds 

IN'3  =  ORU  unit  volume  in  cubic  inches. 

Exhibit  7-4  displays  the  coefficient  and  target  queries  you  specify  for  this 
operation  mode.  As  you  increase  the  relative  size  of  one  coefficient  to  another,  the 
model  will  tend  to  “conserve”  that  total  resource  expenditure.  For  instance,  you  first 
might  wish  to  treat  all  resources  equally,  then  enter  a  “1”  for  each  coefficient  and 
specify  your  targets.  After  the  model  runs,  you  notice  that  weight  is  the  only  resource 
at  (just  below)  its  target.  Run  the  model  again  with  all  the  same  input,  but  this  time 
enter  an  “8”  for  the  weight  coefficient.  Now  weight  has  relatively  greater  importance 
than  the  other  two  coefficients.  The  model  will  try  to  conserve  weight,  sacrificing  cost 
and  volume.  The  result  is  the  station  availability  increases  under  the  same  resource 
constraints. 

You  might  wonder  why  we  suggested  an  8  as  the  weight  coefficient.  Why  not 
a  5?  Is  it  necessary  to  try  every  possible  combination?  The  answer  to  the  last 
question  is  yes,  to  some  degree.  That  is  why  we  have  developed  a  multiple-pass 
version  of  the  model  that  will  automatically  vary  the  coefficients  for  you.  That  is  the 
topic  of  our  next  section. 

MULTIPLE-PASS  MODE 

The  purpose  of  the  multiple-pass  mode  is  to  perform  incremental  tradeoffs 
between  two  resources  and  to  present  the  possible  solutions.  In  Chapter  3,  we 
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discussed  how  the  model  varies  the  relative  importance  (the  coefficient)  of  two 
resources  and  generates  the  cost-versus-weight  solutions  of  Exhibit  3-1.  In  this 
section,  we  discuss  the  user  inputs  that  were  used  to  generate  that  exhibit  and  the 
types  of  analyses  the  model  can  perform. 


Once  you  select  the  multiple-pass  mode  of  operation,  a  screen  similar  to 
Exhibit  7-5  displays  model  queries.  For  this  mode,  the  model  varies  the  relative 
importance  of  two  resource  t3rpes  at  a  time,  though  all  three  resources  are  included  in 
the  unit  resource  Equation  7-2.  Select  a  resource  tradeoff  by  pressing  “Tab”  and  then 
the  “  I  ”  key  to  highlight  the  desired  tradeoff  (a  dot  appears  in  front  of  the  selection ). 
For  example,  select  a  price-versus-weight  tradeoff,  then  select  the  next  query,  “enter 
a  coefficient  not  in  the  chosen  tradeoff,”  or  the  volume  coefficient.  Pressing  the  “Tab” 
key  also  lets  you  move  to  enter  target  values.  When  you  are  finished,  press  the 
“Enter”  key  to  start  the  current  model  year  run. 


Run  Exit 


[■1» 


Multiple-Pass  Mode  Dialog 


r 

I  Select  desired  Trade  Off 

I  (•)  Price-vs-Weight 

(  )  Price-vs-Volume 

(  )  Height-vs-Volume 

Enter  Coefficient  not  in  chosen  Tradeoff: 

Enter  Cumulative  Volume  Target  in  cubic  inches: 
Enter  Cumulative  Price  Target  in  SlOOOs: 

Enter  Cumulative  Weight  Target  in  pounds: 

Enter  Availability  Target  from  0  to  100  percent: 


Model  Year: 
Fiscal  Year: 
Crit  Code: 


1 

1998 

1 


Tab-Return  OK-Done 


Esc  Cancel  Tab  Next  Query 


FI  Menu 


Ctrl -Break  Exit 


EXHIBIT  7-5.  MULTIPLE-PASS  MODE 

Notice  that  in  Equation  7-2  the  three  resource  coefficients  used  in  Equation  7-1 
cp,  CIO,  and  cv  are  now  modified  to  c,  (1  — c),  and  a  constant,  respectively.  If  you 
selected  a  different  resource  tradeoff  in  the  first  query,  then  c  is  the  coefficient  for  the 
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first  resource,  (1— c)  is  the  coefficient  for  the  other  tradeoff  resource,  and  you  enter 
the  constant  for  the  third  resource  coefficient. 

unit  resourcei  =  {c)%Ki  +  (l— c)LBSi  +  {con8tan£)IN‘Z^  >  [Eq.  7-2] 


where 

i  = 

$K 
LBS 
IN‘3 

constant  = 
c  = 

Pass  = 
MaxPass  = 


ORU  index 

ORU  unit  price  in  $l,000s 

ORU  unit  weight  in  pounds 

ORU  unit  volume  in  cubic  inches 

coefficient  that  is  held  constant  over  all  the  passes 

1 — (Pass/MaxPass) 

pass  number 

maximum  number  of  passes,  set  in  the  OPTIONS.RPT  file. 


For  the  example  in  Chapter  3,  Exhibit  3-1,  the  model  pass  number  ranged  from 
0, 1, 2,  etc.,  up  to  10;  the  price  coefficient,  c,  ranged  from  1, 0.9,  0.8,  etc.,  down  to  0.0; 
and  the  weight  coefficient,  (1-c),  ranged  from  0,  0.1,  0.2,  etc.,  up  to  1,  respectively. 
(For  our  example,  since  we  entered  a  “0”  for  the  volume  coefficient  constant,  volume 
is  basically  not  considered  in  the  unit  resource  equation.)  For  each  pass,  the  relative 
importance  between  price  and  weight  is  adjusted.  That  relative  importance  is  the 
ratio  of  the  coefficients  [(1  — c)/c].  At  Pass  1,  weight  is  about  one-tenth  (0.1/0.9=0.11) 
as  important  as  price.  At  Pass  9,  weight  is  9  times  (0.9/0.1 =9)  more  important  than 
price.  (That  ratio  also  can  be  thought  of  as  a  factor  that  converts  pounds  into  dollars.) 


If  you  increase  the  maximum  pass  number  from  “10”  to  “100”,  Pass  1  now 
makes  weight  one-hundredth  as  important  as  price,  and  Pass  99  makes  weight 
99  times  more  important  than  price.  Thus,  the  maximum  pass  number  is  a  way  to 
increase  the  range  and  refine  resoiu*ce  tradeoffs.  A  large  maximum  pass  number  is 
useful  to  ensure  the  model  has  tested  every  possible  combination,  especially  if  the 
total  resource  magnitudes  are  significantly  different  (e.g.,  unit  volume  is  100  times 
larger  than  unit  weight  on  the  average).  The  key  point  is  that  as  the  resource’s 
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relative  importance  increases,  the  model  “conserves”  or  reduces  its  total  resource 
expenditure. 

Once  the  model  has  nm  all  the  passes,  it  chooses  one  as  a  solution.  It  then 
renms  that  pass  to  generate  the  spares  mix  and  resource- versus-availability  curve. 
In  general,  the  solution  is  the  pass  with  the  greatest  station  availability  given  the 
same  resource  constraints. 

If  you  enter  only  an  availability  target  or  only  a  price  target,  the  model  solution 
is  then  the  pass  that  is  less  than  1  percent  over  the  minimum  price  and  has  the  least 
weight.  Exhibit  7-6  presents  the  pass  solutions  table  from  the  test  drive  discussed 
earlier.  In  that  case,  the  pass  with  the  minimum  price  is  the  first  pass  because  it  does 
not  consider  weight  and  stores  all  spares  on  orbit.  Even  though  there  is  no  weight 
target,  storing  all  spares  on  orbit  is  not  a  practical  solution.  As  discussed  in  Chapter 
3  (see  Exhibit  3-1),  a  solution  that  considers  weight  and  price  near  the  elbow  of  the 
curve  is  preferable.  Other  choices  are  “penny  wise  and  pound  foolish.”  Thus,  the 
model  solution  is  the  pass  with  the  least  weight  that  is  within  1  percent  of  the 
minimum  price.  In  Exhibit  7-6,  that  pass  is  Pass  5.  Pass  5  now  becomes  the  model 
solution.  (It  is  repeated  as  the  last  pass  in  the  exhibit.) 


PASS 

SOLUTIONS: 

^  ssssassxs 

>>=  RESOURCES 

II 

II 

N 

II 

II 

II 

H 

II 

It 

H 

II 

..^^.COEFFICIENTS  = 

........ 

PASS 

AVAIL 

'PRICE:$K 

WElGHT:1bs 

VOLUME: in ‘3 

PRICE 

WEIGHT 

VOLUME 

0 

95.0443 

193306 

26545 

2964042 

1.0000 

0.0000 

0.0000 

1 

95.5527 

196225 

16164 

2179708 

0.9000 

0.1000 

0.0000 

2 

95.5168 

196225 

15717 

2165476 

0.8000 

0.2000 

0.0000 

3 

95.1487 

195285 

14069 

1650340 

0.7000 

0.3000 

0.0000 

4 

95.1044 

195285 

13824 

1637332 

0.6000 

0.4000 

0.0000 

5 

95.0214 

195230 

13556 

1613500 

0.5000 

0.5000 

0.0000 

6 

95.0258 

200420 

11004 

1243078 

0.4000 

0.6000 

0.0000 

7 

95.0070 

200815 

10847 

1233238 

0.3000 

0.7000 

0.0000 

8 

95.0158 

202708 

10514 

1219270 

0.2000 

0.8000 

0.0000 

9 

95.2954 

207611 

10260 

1217178 

0.1000 

0.9000 

0.0000 

10 

95.6330 

403515 

9061 

1143198 

0.0000 

1.0000 

0.0000 

11 

95.0214 

195230 

13556 

1613500 

0.5000 

0.5000 

0.0000 

V _ J 


EXHIBIT  7-6.  PASS  SOLUTIONS  TABLE 
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A  point  about  doing  analyses  with  the  model  in  this  mode:  if  you  want  a 
complete  range  of  tradeoffs  between  two  resources,  only  set  an  availability  target;  if 
you  want  the  best  solution  for  a  number  of  targets,  enter  the  targets.  However,  if  you 
enter  the  targets,  the  resource  tradeoff  curve  then  becomes  less  informative. 

GROUND-STOCK-ONLY  MODE 

The  ground-stock-only  mode  is  selected  when  the  ORU  data  base  contains  ORUs 
whose  spares  are  only  stored  on  the  ground.  Those  units  are  usually  the  noncritical 
ORUs  (Criticality  Code  3)  for  which  station  availability  is  less  meaningful.  With  no 
on-orbit  spares,  the  station  availability  is  determined  largely  by  the  probability  of  no 
failures  over  the  cycle.  Calculated  availability  is  typically  low,  reflecting  the 
decision  that  some  shortages  of  spares  of  these  items  can  be  tolerated.  Because  of 
that,  we  have  modified  the  model  to  use  a  more  meaningful  availability  measure, 
ground  availability.  This  is  a  measure  of  probability  that  all  ORUs  have  sufficient 
ground  spares  to  replace  all  failures  from  the  previous  logistics  cycle.  Using  the 
ground  availability  measure  does  not  affect  the  spares  selection  process  we  discussed. 

Since  no  spares  are  stored  on  orbit,  this  operational  mode  is  only  concerned  with 
one  resource,  price.  Therefore,  the  price  coefficient  is  automatically  set  to  1  (the  rest 
are  set  to  0).  You  must  select  between  a  ground  availability  or  a  price  target. 
Exhibit  7-7  shows  the  queries  available  when  you  choose  this  option.  First  press  the 
“Tab”  key  and  select  the  target  type  with  the  “  |  ”  key.  Once  you  selected  a  target, 
press  “Tab”  again  and  enter  the  target  in  the  box  (a  value  between  0  to  100  if  you 
previously  selected  an  availability  target  or  a  value  in  thousands  of  dollars  if  you 
previously  selected  a  price  target).  Finally,  you  press  return  to  start  the  current 
model  year  run. 

MINIMUM  SPARES  EVALUATION  MODE 

(This  option  is  currently  not  available.) 

GLOBAL  ORU  POS  MODE 

The  global  ORU  probability  of  sufficiency  (POS)  mode  is  available  because  it 
provides  a  common  starting  point  since  many  NASA  work  packages  are  familiar  with 
the  POS  measure.  For  the  POS  mode  of  operation,  the  model  selects  enough  spares  so 
that  each  ORU  POS  is  greater  than  or  equal  to  a  user-specified  POS  target.  The  POS 
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EXHIBIT  7-7.  GROUND-STOCK-ONLY  MODE 


Global  ORU  POS  Mode  Dialog 


Enter  that  POS  Target;  0  to  lOOX 


Model  Year; 
Fiscal  Year 
Crit  Code; 


Cancel 


FI  Menu  M.T-X  Exit 


Tab-Return  OK-Done 


Esc  Cancel 


EXHIBIT  7-8.  GLOBAL  ORU  POS  MODE 
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is  estimated  by  a  Poisson  distribution  (see  Equation  4-1)  with  a  mean  equal  to  the 
mean  broken  spares  and  uses  Equation  4-2. 

Once  the  user  selects  this  mode,  the  model  asks  for  the  global  target  POS  (see 
Exhibit  7-8),  Enter  the  POS  target  from  “0”  to  “100”  (percent).  This  mode  only 
considers  ground  performance  similar  to  the  groimd-stock-only  mode.  The  purpose  of 
this  alternative  is  not  to  generate  a  spares  list  but  to  give  users  a  familiar  value  to 
compare  with  those  of  the  optimization  model  runs. 
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CHAPTER  8 


MODEL  OUTPUTS 


Running  the  model  produces  two  files.  One  model  output  file  (BUDGET.RPT) 
summarizes  the  budget  results  and  targets  across  all  criticalities  and  fiscal  years. 
The  other  output  file  (OUT.RPT)  presents  the  basic  inputs  and  detail  spares 
requirements  by  criticality  and  model  year.  To  better  understand  this  chapter’s 
discussion,  you  may  want  to  follow  along  by  browsing  the  files  using  the  supplied 
editor  (select  the  “View”  menu  option  and  then  select  the  appropriate  file).  We  will 
first  discuss  BUDGET.RPT  and  then  OUT.RPT. 

THE  BUDGET  OUTPUT  FILES  (BUDGET.RPT) 

The  model  produces  four  types  of  budget  output  tables.  The  first  table  is  the 
annual  budget  by  model  year  and  criticality.  That  table  gives  summary  results  so 
that  the  user  can  target  the  model  to  select  spares  based  upon  the  POP  marks  (as 
described  in  Chapter  9).  The  other  three  tables  produce  gross  spares  requirements, 
net  spares  requirements,  and  spares  budget  estimates  by  ORU  and  fiscal  year.  Those 
tables  reflect  the  methodology  described  in  Table  1-2.  All  tables  are  formatted  so  that 
they  can  be  imported  to  spreadsheet  software  for  further  manipulation  (as  discussed 
in  Chapter  6). 

Annual  Budgets  by  Model  Year  and  Criticality 

An  important  function  of  M-SPARE  is  to  determine  what  spares  are  required 
given  the  POP  marks.  Although  both  M-SPARE  inputs  and  POP  marks  are 
presented  in  constant  dollars  and  closely  linked,  the  two  differ  significantly.  The 
total  annual  budgets  by  model  run  year  table  (see  Exhibit  9-1)  helps  the  usei 
determine  which  M-SPARE  targets  to  input  so  that  the  resulting  budget  equals  the 
POP  marks.  We  discuss  this  process  in  Chapter  9. 

Gross  Spares  Requirements  by  Fiscal  Year  Table 

The  table  in  Exhibit  8-1  displays  the  gross  spares  requirements  by  ORU  and  by 
fiscal  year.  (The  requirements  do  not  include  replaced  condemnations.)  The  table 
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also  presents  information  on  each  ORU  unit  price,  part  number,  CAGE  numbers,  and 
PLT  spread  vector  (to  the  right  of  the  fiscal  year). 


GROSS  SPARES  REQUIREMENTS  BY  FISCAL  YEAR 


> 

ID  NAME (18) 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

1 

"RADIATOR 

0.0 

0.0 

0.0 

0.0 

2.0 

2.0 

2.0 

2 

"PFCS 

0.0 

0.0 

0.0 

0.0 

3.0 

3.0 

4.0 

3 

"BATTERY  ORU 

0.0 

0.0 

0.0 

0.0 

3.0 

5.0 

8.0 

4 

"BCOU 

0.0 

0.0 

0.0 

0.0 

6.0 

8.0 

13.0 

5 

"DC  SWITCH  UNIT 

0.0 

0.0 

0.0 

0.0 

5.0 

7.0 

10.0 

V _ J 


EXHIBIT  8-1.  GROSS  SPARES  REQUIREMENTS  BY  FISCAL  YEAR 


Net  Spares  Requirements  with  Replaced  Condemnations  by  Fiscal  Year  Table 

The  table  in  Exhibit  8-2  presents  the  net  spares  by  ORU  and  fiscal  year  smd 
includes  replaced  condemnations.  The  model  calculates  the  net  spares  for  a  fiscal 
year  by  finding  the  gross  spares  requirements  of  the  fiscal  year  minus  the  gross 
spares  requirements  of  the  previous  fiscal  year  plus  replaced  condemnations  (see 
Chapter  4  for  more  discussion). 


NET  SPARES  REQUIREMENTS 

INCLUDING  REPLACED  CONDEMNATIONS 

BY  FISCAL 

YEAR 

> 

ID  NAME (18) 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

1 

"RADIATOR 

« 

0.0 

0.0 

0.0 

0.0 

2.0 

0.0 

0.0 

2 

"PFCS 

N 

0.0 

0.0 

0.0 

0.0 

3.0 

0.0 

1.0 

3 

"BATTERY  ORU 

It 

0.0 

0.0 

0.0 

0.0 

3.0 

2.0 

3.0 

4 

"BCOU 

It 

0.0 

0.0 

0.0 

0.0 

6.0 

2.0 

5.0 

5 

"DC  SWITCH  UNIT 

n 

0.0 

0.0 

0.0 

0.0 

5.0 

2.0 

3.0 

EXHIBIT  8-2.  NET  SPARES  REQUIREMENTS 


Spares  Budget  Estimates  by  Fiscal  Year  Table 

The  table  in  Exhibit  8-3  presents  the  spares  budgets  by  ORU  and  fiscal  year.  It 
is  similar  to  the  bottom  half  of  Table  l-2c  where  spares  buys  are  multiplied  by  imit 
costs  and  then  spread  across  the  PLT.  At  the  bottom  of  Exhibit  8-3  is  the  final  budget 
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for  all  ORUs.  Budget  values  are  presented  in  thousands  of  constant  dollars  based 
upon  the  baseline  dollar  year  of  the  unit  price.  Thus,  to  estimate  budgets  in  current- 
year  dollars,  you  must  inflate  M-SPARE  constant  dollar  estimates.  Since  different 
work  packages  use  different  inflation  rates,  that  final  step  is  left  to  you. 


•  4 

SPARES  BUDGET 

ESTIMATES  BY 

FISCAL 

YEAR  IN 

1000 'S  OF 

CONSTANT 

DOLLARS 

> 

ID  NAME (18) 

1994 

1995 

1996 

1997 

1998 

1999 

1 

"RADIATOR 

N 

0.0 

0.0 

3502.8 

2335.2 

0.0 

1751.4 

2 

"PEGS 

M 

0.0 

3205.8 

5343.0 

3205.8 

1781.0 

712.4 

3 

"BATTERY  ORU 

n 

0.0 

1075.5 

2509.5 

2987.5 

4063.0 

10157.5 

4 

"BCDU 

M 

0.0 

2678.4 

5356.8 

5505.6 

5208.0 

3422.4 

5 

"DC  SWITCH  UNIT 

H 

0.0 

793.5 

1639 . 9 

1534.1 

1005.1 

476.1 

>  BUDGET  TOTAL 

0 

20505 

60536 

61295 

50100 

41802 

(SK)  /  FISCAL  YEAR: 

1994 

1995 

1996 

1997 

1998 

1999 

Annual  Model  Budget 

0 

60536 

61295 

50100 

41802 

Cumulative  Model  Budget 

0 

20505 

81041 

142336 

192436 

234237 

Cumulative  POP  Marks 

0 

0 

5000 

32000 

88000 

156000 

V. 


j 


EXHIBIT  8-3.  SPARES  BUDGET  ESTIMATES  BY  FISCAL  YEAR 


DETAILED  SPARES  REQUIREMENT  FILES  (OUT.RPT) 

The  other  output  file  (OUT.RPT)  that  M-SPARE  produces  presents  more 
detailed  model  inputs  and  spares  requirements  outputs.  The  data  are  first  separated 
into  different  criticality  codes,  then  into  model  year  nms.  For  each  criticality  code, 
the  nie  contains  a  launch  schedule,  demand  summary,  QPA  profile,  and  user  input 
table  for  all  model  years.  It  presents  six  other  tables  that  are  repeated  by  model  year. 
At  the  end  of  the  file  is  the  resource  summary  table.  The  different  table  locations  are 
mapped  out  in  Table  8-1.  Descriptions  of  the  various  tables  in  the  file  are  as  follows: 

•  Elemert  Launch  Schedule  Table.  Displays  the  monwU  and  year  of  each  ele¬ 
ment  launch. 

•  QPA  Profile  Table.  Displays  the  total  QPA  by  month  and  model  fiscal  year. 
Each  ORU  is  in  a  separate  subtable. 

•  Demand  Summary  Table.  Displays  mean  orbit  failures,  mean  broken 
spares,  replaced  condemnations,  and  VMR  by  model  fiscal  year.  Each  ORU 
is  in  a  separate  subtable. 
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•  User  Inputs  and  Options  Table.  Shows  the  user  inputs  entered  and  the 
model  options  selected  from  the  OPTIONS.RPT  file. 

•  ORU  Input  Data  Table.  Shows  the  ORU  input  information  from  the 
MSPAREIN.RPT  file  for  each  model  year. 

•  Pass  Solutions  Table.  Shows  the  station  availability  and  resource 
information  at  the  solution  point  for  each  pass  of  the  model. 

•  Spares  Mix  for  Solution  Point  Table.  Shows  the  spares  requirements  (on 
orbit  and  ground)  for  the  best  pass  solution. 

•  Distributed  Systems  Results  Table.  Shows  the  availability  and  station 
resource  expenditures  disaggregated  to  a  distributed  system  level. 

•  Resource-Versus- Availability  Curve  Table.  Presents  the  data  used  for  the 
curve  in  tabular  form. 

•  Resource  Summary  Table.  Shows  the  weight  and  volume  of  Criticality 
Code  1  ORUs  stored  on  orbit  and  all  ORU  codes  resupplied  each  year. 

Each  output  table  is  discussed  in  a  separate  subsection  of  our  guide  and  is 
identified  by  the  table  title. 

Element  Launch  Schedule  Table 

If  your  ORU  input  data  is  by  element  laimch,  the  model  produces  the  launch 
schedule  (see  Exhibit  8-4).  The  first  column  in  this  table  displays  the  M-SPARE 
element  number,  which  corresponds  to  the  order  of  the  elements  in  the 
OPTIONS.RPT  file  and  the  ORU  input  file.  The  next  two  columns  present  the 
element  launch  dates  in  calender  month  and  year  (the  information  you  entered  in  the 
OPTIONS.RPT  file).  The  final  two  columns  present  the  launch  by  fiscal  month  and 
year.  Since  most  people  use  calender  timeframes  while  M-SPARE  uses  fiscal 
timeframes,  we  present  the  translation  for  you.  A  fiscal  timeframe  places  the  launch 
3  months  later  than  calender  information. 

QPA  Profile  Table 

The  QPA  profile  presents  the  total  QPA  (summed  across  all  elements)  by  month 
and  model  fiscal  year  for  each  ORU  (see  Exhibit  8-5).  QPA  is  the  only  demand 
variable  that  changes  from  one  model  year  to  the  next.  Depending  on  the  format  of 
your  ORU  input  data,  the  QPA  could  change  each  fiscal  year  (i.e.,  each  row)  or  on  a 
specific  month  of  the  element  launch.  If  the  input  data  is  by  element  launch,  the  QPA 
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TABLE  8-1 


TABLE  LAYOUT  OF  OUT.RPT  FILE 


Criticality  Code  1 

Element  Launch  Schedule  Table 
QPA  Profile  Table 
Demand  Summary  Table 
User  Inputs  and  Options  Table 
First  Model  Year 

ORU  Input  Data  Table 
Pass  Solutions  Table 
Spares  Mix  for  Solution  Point  Table 
Distributed  Systems  Results  Table 
Resource-Versus-Availability  Curve  Table 
Second  Model  Year  (same  type  of  tables  as  first  year) 
• 

Criticality  Code  2  (same  type  of  tables  as  Code  1) 

Criticality  Code  3  (same  type  of  tables  as  Code  1) 


Resource  Summary  Table 


profile  is  followed  by  a  list  of  QPA  quantities  by  element.  If  the  ORU  is  a  wear  item, 
the  simulation  input  file  (PREPIN.DAT)  contains  the  QPA  profiles. 

Demand  Summary  Table 

The  table  in  Exhibit  8-6  contains  detailed  demand  information  by  ORU  and  by 
model  year.  The  purpose  of  the  table  is  to  display  the  most  detailed  calculations  of 
the  model.  (You  might  want  to  skip  this  information  initially.)  Each  column  of  the 
ORU  matrix  corresponds  to  different  factors  such  as  the  mean  orbit  failures,  the 
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Element  Launch 

Schedule 

Element 

#  Ca1ender:Mth 

Year  | 

Fiscal :Mth 

FY 

1 

10 

1995 

1 

1996 

2 

10 

1999 

1 

2000 

3 

4 

2001 

7 

2001 

J 


EXHIBIT  8-4.  ELEMENT  LAUNCH  SCHEDULE  TABLE 


(  \ 

ORUm  1  EXAMPLE  STATION  ORU  LogCycle^^  180  NOT  a  wear  item 

QPA  BY  MONTH  (COL),  YEARS  (ROW) 

1  2  3  4  5  6  7  8  9  10  11  12 


1996  2 

1997  2 

1998  2 

1999  2 

2000  4 

2001  4 

2002  6 

2003  6 

2004  6 

2005  6 

Element  # 
Element  QPA 

V 


2  2  2 

2  2  2 

2  2  2 

2  2  2 

4  4  4 

4  4  4 

6  6  6 

6  6  6 

6  6  6 

6  6  6 

1  2  3 

2  2  2 


2  2  2  2 

2  2  2  2 

2  2  2  2 

2  2  2  2 

4  4  4  4 

4  4  6  6 

6  6  6  6 

6  6  6  6 

6  6  6  6 

6  6  6  6 


2  2  2  2 

2  2  2  2 

2  2  2  2 

2  2  2  2 

4  4  4  4 

6  6  6  6 

6  6  6  6 

6  6  6  6 

6  6  6  6 

6  6  6  6 


J 


EXHIBIT  8-5.  QPA  PROFILE  TABLE 


mean  broken  spares  (number  of  unserviceable  ORUs),  the  replaced  condemnations, 
and  the  VMR.  We  discuss  each  variable  in  Chapter  4.  However,  if  the  ORU  uses  the 
wear  simulation,  we  discuss  those  factors  in  Chapter  10. 

User  Inputs  and  Options  Table 

The  next  table  in  the  OUT.RPT  file  displays  user  inputs  from  the  query  session 
and  model  options  from  the  OPTIONS.RPT  file.  The  table  first  displays  the 
availability  and  resource  (price,  weight,  and  volume)  targets.  Remember,  a  target 
number  that  shows  a  string  of  9s,  indicates  you  entered  a  “0”  (do  not  consider)  for  the 
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AT  ORU  1  EXAMPLE  STATION  ORU 


Model  YR 

Mean  Orbit 

Mean  Broken 

Replace  Condemn. 

VMR 

1996 

4.00 

4.00 

0.00 

1.00 

1997 

4.00 

6.00 

0.00 

1.00 

1998 

4.00 

8.00 

0.00 

1.00 

1999 

4.00 

8.00 

2.00 

1.00 

2000 

8.00 

12.00 

2.00 

1.00 

2001 

12.00 

14.00 

2.00 

1.00 

2002 

12.00 

21.00 

2.00 

1.00 

2003 

12.00 

23.00 

4.00 

1.00 

2004 

12.00 

24.00 

5.00 

1.00 

2005 

12.00 

24.00 

6.00 

1.00 

v _ y 


EXHIBIT  8-6.  DEMAND  SUMMARY  TABLE 


target  value  and  the  model  reset  it  to  a  maximum  value  to  implement  your  direction. 
The  last  lines  in  the  table  show  the  global  values  for  all  the  model  options. 

ORU  Input  Data  Table 

The  next  table  is  the  ORU  input  data  read  from  the  MSPAREIN.RPT  file.  The 
column  headings  of  the  table  are  similar  to  the  input  file  headings  defined  in 
Chapter  5,  but  with  four  modifications.  The  file  contains  only  the  first  20  characters 
of  the  name  field.  Mean  orbit  demand  is  the  mean  demand  in  a  logistics  cycle  for  all 
ORU  applications  for  a  specific  model  year  and  is  the  product  of  several  input  fields 
(see  Equation  4-8).  The  VMRs  from  the  ORU  input  that  are  less  than  1  are  slightly 
modified  so  that  the  binomial  distribution  produces  valid  results.  Mean  broken 
indicates  the  mean  number  of  unserviceable  (broken)  units  in  the  maintenance 
process  (see  Equation  4-6). 

Pass  Solutions  Table 

A  pass  solution  is  the  point  on  the  resource-versus-availability  curve  at  which 
one  of  the  station  targets  is  exceeded.  The  pass  solutions  table  displays  the 
availability,  resources,  and  coefficients  for  each  pass  solution.  The  model  selects 
those  solutions  as  the  best  pass  (see  Exhibit  7-6  and  discussion).  The  best  pass  data 
are  repeated  at  the  bottom  of  the  pass  solutions  table  and  also  used  to  help  generate 
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the  initial  spares  list  that  follows.  All  resources  are  cumulative  (for  past  and  present 
years). 

Spares  Mix  for  Solution  Point  Table 

The  key  model  output  is  the  mix  of  spares  that  maximizes  availability  given  a 
set  of  targets  and  resource  coefficients.  In  the  spares  mix  table  (see  Exhibit  8-7),  the 
spares  solution  point  on  the  resource-versus-availability  curve  is  given  first.  (With 
multiple  passes,  the  selected  solution  point  is  the  best  pass.)  Next,  the  table  lists  each 
ORU’s  name  and  respective  gross  spares  requirements  (both  on  orbit  and  on  the 
ground),  the  assets,  and  the  net  spares  requirements  (requirements  minus  assets). 
The  on-orbit  and  ground  spares  are  the  results  of  the  optimal  solution.  The  next 
column  is  the  ORU  PSN  (see  Chapter  4).  If  you  multiply  the  individual  PSNs 
together,  you  will  quantify  the  predicted  station  availability.  The  next  column  in  the 
spares  mix  table  is  the  annual  investment  price  (the  net  spares  times  the  unit  price) 
for  each  ORU.  The  last  columns  give  the  breakdown  of  the  asset  value.  “Assets” 
equal  previous  years’  gross  spares  minus  replaced  condemnations.  If  the  starting 
spares  option  (see  Chapter  6)  is  set  to  “0”,  the  model  ignores  previous  assets  (i.e., 
asset  position  is  set  to  0),  and  the  entire  spares  mixes  are  selected  in  that  year. 


(  ^ 
=  MIX  FOR  SOLUTION  POINT  =  =  =  **==  =  =  =  ===  =  =  =  =  *  =  =  ====.  =  =  =  . 

CRITICALITY  CODE  1  YEAR  2000 

"  AVAILABILITY  95.09  RESOURCE  104393.00  ’.—Asset  Breakdown-;  " 

"  I - INITIAL  SPARES  — |  Last  Yrs  _  Condemns 


”  ORU  NAME  Orbit+Ground 

-Assets  = 

Net 

PSN 

SK 

SpareSoln 

ThisYr 

1  "RADIATOR 

1 

1 

2 

0 

99.13 

0.0 

2 

0 

2  "PFCS 

3 

1 

3 

1 

99.52 

3562.0 

3 

0 

3  "BATTERY  ORU 

3 

5 

5 

3 

99.87 

3585.0 

5 

0 

4  "BCDU 

6 

7 

8 

5 

99.68 

7440.0 

8 

0 

5  "DC  SWITCH  UNIT" 

4 

6 

7 

3 

99.95 

1587.0 

7 

0 

EXHIBIT  8-7.  SPARES  MIX  FOR  SOLUTION 


Distributed  Systems  Results  Table 

The  distributed  systems  results  table  is  a  more  detailed  breakdown  of  the 
station  solution  point  discussed  above  and  is  derived  in  a  similar  manner.  The  table 


8-8 


in  Exhibit  8-8  shows  those  results  from  our  test  drive.  The  bottom  line  of  that  table 
gives  the  station  spares  solution  point  on  the  curve  (95.08)  as  well  as  the  cumulative 
prices,  weight,  and  volume  of  the  gross  spares  requirements  (note  the  price  value  does 
not  include  replaced  condemnations  so  it  differs  from  other  price  values).  The  table 
also  lists  the  number  of  distinct  ORUs  (“#  ORUs”),  and  the  nxunber  of  spares  selected 
(‘‘Spares”).  The  table  disaggregates  the  total  space  station  system  results  to 
distributed  systems.  The  distributed  systems  are  ORU  subsets  of  the  total  space 
station  and  are  defined  by  the  DIST  SYSTEM  field  of  the  ORU  input  data.  The  model 
calculates  the  system  results  for  each  ORU  subset  in  a  similar  manner  as  the  station 
results.  For  instance,  a  distributed  system  availability  is  the  product  of  its  ORU’s 
PSN.  Each  ORU  must  be  associated  with  a  single  distributed  system. 


=  «  =  =  =  =  =  =  =  =  =  =  =  =  :,  =  =:  =  =  =  =  =  DISTRIBUTED  SYSTEMS  RESULTS  ==  =  =  =  =  =  =  =  =  =  *  =  = 


SYSTEM 

6 

12 

AVAILABILITY 

97.7831 

97.2455 

•PRICE 

78731.00 

116262.00 

WEIGHT 

7261 

6295 

VOLUME 

903736 

709764 

tt  ORUs 

8 

18 

SPARES 

52 

149 

STATION 

95.0897 

194993.00 

13556 

1613500 

26 

201 

(*  price  does  not  include  replaced  condemnations) 


EXHIBIT  8-8.  DISTRIBUTED  SYSTEMS  RESULTS  TABLE 

Resource-Versus-Availability  Curve  Table 

The  resource-versus-availability  curve  table  shows  all  the  points  that  make  up 
the  curve.  Point  by  point  (spare  by  spare),  the  table  lists  the  station  availability, 
accumulated  resources,  and  the  ORUs  selected.  The  table  starts  with  the  current 
asset  position  or  all  spare  levels  at  0  (no  resources  expended  for  the  first  fiscal  year) 
and  ends  when  the  station  availability  reaches  99  percent  (the  maximum  availability 
set  in  the  OPTIONS.RPT  file). 

Resource  Summary  Table 

The  purpose  of  this  table  is  to  present  a  complete  picture  of  the  spares  weight 
(sometimes  referred  to  as  “upmass”)  and  volume  launched  into  space.  To  do  that  the 
model  estimates  the  weight  and  volume  for  two  resource  categories:  (1)  the  spares 


8-9 


stored  on  orbit  for  the  Criticality  Code  1  ORUs  (see  top  of  Exhibit  8-9)  and  (2)  the 
spares  “resupplied”  to  SSF  to  replace  failures  for  Criticality  Codes  1,  2,  and  3  ORUs 
(see  bottom  of  Exhibit  8-9).  We  discussed  the  weight  and  volume  of  spares  stored  on 
orbit  already  and  displayed  the  results  in  the  pass  solutions  table  and  the  resource- 
versus-availability  curve  table.  We  will  now  discuss  the  weight  and  volume  of  the 
resupplied  spares. 

RESOURCE  SUMMARY  (VOLUME  &  WEI6HT/UPMASS) ^ 


Station  Configuration  Fiscal  Year 

1998 

1999 

2000 

2001 

On-orbit  Spares  Resources  for  Crit 

Code  1 

Cumulative  Orbit  Spares  Volume: In'3 
Cumulative  Orbit  Spares  Weight:1bs 
Annual  Orbit  Spares  Weight:lbs 
Resupply  Resources  (Unit  Resource  * 

0 

0 

0 

Oemands/Yr) 

0 

0 

0 

for  all  crit 

1613500 

13556 

13556 

codes 

1264998 

11107 

0 

Annual  Resupply  Weight, all  0RUs:lbs 
Annual  Resupply  Volume, all  ORUsrIn* 

2329 

3  254060 

3726 

411017 

4308 

457334 

4832 

490869 

EXHIBIT  8-9.  RESOURCE  SUMMARY  TABLE 

The  M-SPARE  model  assumes  that  if  a  failure  occurs,  the  next  shuttle  will 
resupply  the  station  with  a  spare  (if  available)  to  replace  the  failure.  That  is  true  for 
all  ORU  criticalities  codes  except  Criticality  Code  1.  With  Criticality  Code  1  ORUs, 
astronauts  may  have  already  replaced  the  failure  with  a  spare  from  the  on-orbit 
inventory.  In  that  case,  the  resupplied  spare  replenishes  the  on-orbit  inventory.  To 
estimate  the  resupply  weight  and  volume,  M-SPARE  multiples  an  ORU’s  average 
number  of  failures  in  a  year  times  its  unit  resource  requirement  and  then  sums  across 
all  ORUs  for  all  criticalities.  The  model  calculates  annual  failures  by  summing  all 
failures  that  occur  for  the  previous  12  months,  starting  at  the  most  recent  laimch 
month  and  moving  backwards. 

For  consistency,  M-SPARE  presents  the  on-orbit  weight  and  volume  estimates 
(as  well  as  price  estimates)  as  cumulative  values  for  past  and  present  years. 
However,  weight  estimates  really  are  somewhat  different  since  unused  launch 
capacity  in  1  year  cannot  be  applied  in  following  yesirs.  (That  is  not  the  case  for 
volume  capacity.)  Thus,  for  some  applications,  it  is  appropriate  to  consider  annual 
values  (the  difference  between  successive  cumulative  values)  on-orbit  spares  weight. 
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Thus,  Exhibit  8-8  also  presented  annual  values.  For  similar  reasons,  Exhibit  8-9 
presented  resupply  weight  and  volume  as  annual  estimates  rather  than  as 
cumulative  estimates. 
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CHAPTER  9 


M’SPARE  USE  FOR  THE  PROGRAM  OPERATING  PLAN 


The  SSF  project  offices  primarily  uses  M-SPARE  to  produce  spares  estimates 
and  funding  estimates  for  their  annual  POP  cycle.  M-SPARE  produces  three  basic 
products  for  the  POP  cycle.  The  following  products  will  each  be  discussed  in  a 
separate  section: 

•  Spares  Requirements  Product  For  the  first  POP  product,  M-SPARE 
estimates  what  spares  the  station  requires  to  reach  a  specified  availability 
target.  As  always,  the  mix  is  optimal  and  is  the  least  cost  mix  to  reach  the 
availability  target,  but  no  overall  funding  constraint  is  applied.  To  produce 
that  product,  the  user  enters  annual  availability  targets  and  the  model 
estimates  the  spares  requirements  (as  we  described  in  Chapter  1  and  in  the 
test  drive  in  Chapter  2). 

•  Constrained  Budget  Product  For  the  next  POP  product,  the  user  specifies 
the  expected  annual  budgets  (POP  marks),  and  M-SPARE  determines  how 
many  spares  NASA  can  acquire  for  the  money.  We  will  discuss  this  product 
in  detail  since  it  is  more  complicated  to  generate  than  the  others. 

•  Development  and  Operational  Product.  This  product  produced  a  further 
breakdown  of  requirements  into  two  subcategories:  spares  requirement  that 
support  the  station  in  the  first  year  of  the  ORU’s  life  and  spares 
requirements  that  support  the  ORU  thereafter.  For  the  purpose  of  this 
guide,  we  term  those  two  subcategories  as  "Development”  and  "Operational” 
requirements,  respectively. 

For  all  POP  products  and  criticality  codes,  the  user  usually  runs  the  model  with 
the  ground-stock-only  option.  The  exception  is  for  spares  designated  Criticality 
Code  1.  For  Criticality  Code  1,  the  user  usually  assumes  ground-stock-only  through 
FY99  then  both  on-orbit  and  groimd  stock  thereafter.  That  means  the  user  selects 
the  ground  option  through  FY99  and  then  selects  the  multiple-pass  option  for  the 
remaining  model  years.  We  will  now  discuss  each  of  the  M-SPARE  products  in 
greater  detail. 
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SPARES  REQUIREMEr'TS  PRODUCF 


For  the  spares  requirements  product,  the  model  determines  what  spares  NASA 
would  like  to  have  given  only  an  availability  target  (i.e.,  no  funding  constraints).  The 
user  inputs  yearly  availability  targets  and  M-SPARE  generates  spares  requirements 
for  the  first  years  of  the  station’s  life  (e.g.,  FY96  through  FY04).  It  also  estimates  the 
corresponding  funding  requirements  for  the  next  9  fiscal  years  (e.g.,  FY94  through 
FY02)  to  meet  those  specified  targets.  The  availability  targets  usually  vary  by 
criticality  code  —  an  availability  of  95  percent  for  Criticality  Code  1  and  an 
availability  of  85  percent  for  Criticality  Codes  2  and  3.  The  availability  targets  can 
also  vary  by  year  although  for  the  last  POP  cycle,  they  remained  constant.  For  more 
information,  see  the  overview  discussion  in  Chapter  1,  the  detailed  operating 
instructions  in  Chapter  7,  or  the  model  demonstration  in  Chapter  2. 

CONSTRAINED  BUDGET  PRODUCT 

For  the  constrained  budget  product,  the  user  specifies  annual  budgets  for  the 
next  9  fiscal  years  (the  POP  marks),  and  M-SPARE  determines  how  many  spares 
NASA  can  obtain  with  those  funds.  The  constrained  product  is  more  lifficult  to 
produce  than  the  requirements  product  because  budget  estimate"  typically  an 
output,  not  an  input,  of  M-SPARE.  Though  M-SPARE  can  use  an  input  in  dollars, 
those  dollars  are  very  different  from  budget  dollars.  M-SPARE  requires  inputs  based 
upon  a  speciHc  fiscal  year  in  the  SSF’s  life  and  those  inputs  are  actually  the 
cumulative  spares  resources  (weight,  volume,  and  price).  M-SPARE  uses  cumulative 
price  because  station  availability  is  based  upon  the  entire  inventory,  not  just  the 
incremental  spares  delivered  for  the  year.  Budgets  are  incremental  actions  over 
several  years  that  eventually  result  in  spares  deliveries.  Thus,  the  budget  level 
determines  the  incremental  dollar  “lay-away”  plan  required  for  future  spares 
deliveries;  on  the  other  hand,  M-SPARE  price  inputs  are  the  cumulative  (past  and 
present)  investments  of  the  delivered  spares. 

Table  9-1  illustrates  the  distinction  between  the  price  input  and  the  budget 
output.  That  table  continues  our  single  ORU  example  stated  earlier  in  Table  l-2c. 
M-SPARE  requires  the  cumulative  price  as  input  (displayed  in  the  shaded  column)  to 
produce  that  annual  budget  (displayed  second  to  last  row).  If  the  PLT  in  our  example 
was  1  day  (or  NASA  paid  for  the  spares  on  the  delivery  day),  then  the  cumulative 
budget  (shaded  row)  would  equal  the  input  price.  If  the  PLT  was  1  year,  then  the 
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cumulative  budget  would  lag  1  year  behind  the  input  price.  But  since  the  PLT  is 
2  years  and  the  ORU  unit  cost  is  spread  over  both,  the  cumulative  budget  is  quite 
different  from  the  cumulative  price  until  the  last  year.  So,  the  model  must  convert 
the  POP  marks  into  input  price  so  that  M -SPARE  output  approximates  the  POP 
marks.  What  makes  that  process  complicated  is  that  a  POP  mark  in  FY95  can 
impact  two  different  model  years,  FY96  and  FY97.  In  addition,  each  ORU  can  have  a 
different  PLT  (1  to  5  years)  and  can  spread  the  unit  cost  over  that  PLT  differently 
(i.e.,  different  spread  vectors).  We  will  now  discuss  how  the  model  performs  the 
conversion. 


TABLE  9-1 

INVESTMENT  INPUT  VERSUS  BUDGET  OUTPUT 


FY96 

FY97 

FY98 

FY99 

Logistics  cycle 

_ 

D 

g 

g 

5 

D 

D 

Di 

Requirements/LogCycle 

H 

8 

H 

g 

11 

12 

13 

14 

Requirements/year 

■ 

8 

19 

12 

14 

Net  requirements/year 

■ 

8 

■ 

n 

2 

2 

Outlays 

($000) 

FY94 

FY95 

FV96 

FY97 

FY98 

Cumulative 
price  input 

ForSSF  FY96 

600 

400 

tJPOf 

ForSSFFY97 

150 

100 

iiiliiiiiii 

ForSSFFY98 

150 

100 

ForSSFFY99 

150 

100 

1,750 

Annual  budget 

600 

550 

250 

250 

100 

Cumulative  budget 

600 

1,1S0 

I>t00 

lASO 

iwe 

Howto  Target  M-SPARE  to  Match  POP  Marks 

Our  objective  is  to  produce  spares  funding  estimate  by  year  that  are  within  the 
budget  POP  marks.  We  assume  that  the  user  knows  the  annual  POP  marks,  by  year, 
in  current-year  dollars  for  all  criticality  codes.  To  convert  POP  marks  to  cumulative 
price  inputs  the  user  performs  the  following  steps: 

•  Deflate  the  annual  POP  marks  from  the  current  year  to  constant-baseline- 
year  dollars  (the  baseline  year  is  the  dollar  year  of  the  ORU  imit  prices). 
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Disaggregate  your  POP  marks  into  marks  set  by  criticality  codes.  You 
might  want  to  split  the  budget  based  upon  some  fixed  ratio  (e.g.,  50  percent 
for  Criticality  Code  1  ORUs,  30  percent  for  Criticality  Code  2  ORUs,  and 
20  percent  for  Criticality  Code  3  ORUs)  or  perhaps  divide  the  total  POP 
budget  based  upon  the  results  of  the  M-SPARE  requirements  products 
discussed  earlier. 

•  Sum  the  previous  year’s  POP  marks  to  produce  cumulative  marks  by  fiscal 
year. 

•  Insert  the  cumulative  marks  into  the  OPTIONS.RPT  file  (see  Chapter  6). 

•  Run  the  model  using  availability  targets  to  generate  the  spares 
requirements  products  and  allow  the  model  to  “get  smart  enough”  to  make 
an  initial  guess  for  the  input  price. 

•  Rerun  the  model  using  the  “price  guess”  targets  (shaded  area)  generated  as 
part  of  the  total  annual  budgets  by  model  run  year  table  (see  Exhibit  9-1). 
That  price  guess  is  the  cumulative  investment  that  should  reproduce  the 
POP  marks. 

By  rerunning  the  model  a  few  times  using  the  latest  price  guess,  model  results  should 
converge  towards  the  cumulative  POP  marks. 

Targeting  Methodology 

The  table  in  Exhibit  9-1  displays  the  methodology  the  model  uses  to  convert 
POP  marks  into  input  price  targets  (some  of  the  right-hand  columns  are  not 
displayed).  The  top  part  of  the  exhibit  is  the  latest  M-SPARE  output,  and  the  bottom 
part  is  what  M-SPARE  guesses  the  output  needs  to  be  to  match  the  POP  marks.  The 
model  targets  each  criticality  code  separately.  We  first  run  the  model  based  upon 
availability  targets  to  determine  how  the  model  spreads  net  spares  requirements 
dollars  over  previous  fiscal  years.  In  our  exhibit,  we  assume  Criticality  Code  1  ORUs, 
so  we  used  a  95  percent  ground  (Grd)  availability  in  the  first  2  years  and  then  a 
95  percent  station  (Orb)  availability  in  the  remaining  years.  The  top  part  of 
Exhibit  9-1  presents  the  resulting  output.  The  first  columns  of  Exhibit  9-1  present 
the  output  availabilities. 

The  top  part  of  Exhibit  9-1  also  displays  the  dollar  outputs  by  model  year  (the 
rows)  and  the  budget  estimates  (the  columns).  All  values  are  in  thousands  of 
constant  dollars.  Notice  for  model  year  FY98,  the  model  spreads  dollars  back  to 
FY95,  FY96,  and  FY97.  That  spread  is  generate  when  M-SPARE  takes  an  ORU’s  net 
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A 


Total  Annual  Budgets  by  Model  Run  Year  for  CRITICALITY  CODE  1 

All  Values  in  thousands  of  constant  dollars 
(Purpose:  Helps  you  get  model  budgets  equal  to  POP  Marks) 

BUDGET 

Availability/Fiscal  Yea.  1994 

ESTIMATE 

1995 

FROM  ‘LAST*  MODEL 
1998  1997 

RUN 

1998 

1999 

2000 

Grd  96.2/Mode1  Year=  1998 

0 

20505 

50526 

24570 

0 

0 

0 

Grd  95.2/Mode1  Year°  1999 

0 

0 

10010 

21874 

10133 

0 

0 

Orb  95.l/Mode1  Year<  2000 

0 

0 

0 

14493 

29411 

13166 

0 

Orb  95.1/Model  Year*  2001 

0 

0 

0 

0 

10708 

22406 

10178 

Orb  95.1/Model  Year*  2002 

0 

0 

0 

0 

0 

7146 

13489 

Orb  95.0/Model  Year*  2003 

0 

0 

0 

0 

0 

0 

6700 

Orb  95.1/Model  Year*  2004 

0 

0 

0 

0 

0 

0 

0 

Orb  95.1/Model  Year*  2005 

0 

0 

0 

0 

0 

0 

0 

Annual  Model  Budget 

0 

20505 

60536 

60936 

50252 

42718 

30367 

Annual  POP  MARKS 

0 

0 

5000 

2/000 

56000 

68000 

70000 

Cumulative  Model  Budget 

0 

20505 

81041 

141977 

192229 

234947 

265314 

Cumulative  POP  MARKS 

0 

0 

5000 

32000 

88000 

156000 

226000 

Ratio  (Cum.  POP/Model)  0 

.0000 

0.0000 

0.0617 

0.2254 

0.4578 

0.6640 

0.8518 

BUDGET 

ESTIMATE 

FOR  ’NEXT 

•  MODEL  RUN 

Year  Gtieaa  Factor  " 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

1998  9.1  0.00 

0 

0 

0 

0 

0 

0 

1999  20987  0.50 

0 

0 

5000 

10926 

5062 

0 

2000  89894  1.11 

0 

0 

0 

16074 

32620 

14603 

0 

2001  199343  1.71 

0 

0 

0 

0 

18318 

38329 

17411 

2002  211289  2.00 

0 

0 

0 

0 

0 

14303 

27000 

2003  292731.  2.00 

0 

0 

0 

0 

0 

13410 

2004  999779  2.00 

0 

0 

0 

0 

0 

0 

2005  338494  2.00 

0 

0 

0 

0 

0 

0 

Next  Cumulative  Budget 

0 

0 

5000 

32000 

88000 

155235 

213056 

Cumulative  POP  Marks 

0 

0 

5000 

32000 

88000 

156000 

226000 

Ratio  (Cum.  P0P/Mode1 )  999 

.0000 

999.0000 

1.0000 

1.0000 

1.0000 

1.0049 

1.0608 

SUMMARY  BY  MODEL  YEAR 

1998 

1999 

2000 

2001 

2002 

2003 

2004 

Next  Price  Guess 

0.1 

20987.3 

84284.2 

158343.2 

211288.6 

262730.9 

305778.6 

Last  Price  Guess 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Last  Availability  Output 

96.2 

95.2 

95.1 

95.1 

95.1 

95.0 

95.1 

X^verage  Availability 

95.24 

EXHIBIT  9-1.  TARGETING  M-SPARE  TO  POP  MARKS 


spares  requirements  and  applies  the  ORU’s  spread  vector.  Exhibit  9-1  is  the  sum  of 
that  spread  for  all  Criticality  Code  1  ORUs. 

The  model  next  displays  the  annual  model  budget  (the  sum  of  the  colunms)  and 
the  cumulative  model  budget  outputs  (the  sum  of  the  previous  and  current  annual 
values).  For  comparison,  the  model  also  displays  the  annual  and  cumulative  POP 
marks  you  entered  in  the  OPTIONS.RPT  file  earlier.  The  model  next  displays  the 
ratio  of  the  cumulative  POP  marks  to  the  cumulative  model  budget.  Our  objective  is 
to  make  sure  that  ratio  is  greater  than  or  equal  to  1  (i.e.,  the  model  funding  is  always 
within  the  budget). 
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To  do  that  for  our  example,  we  must  reduce  certain  model  year  budgets.  We 
assume  that  the  spread  of  dollars  by  model  year  does  not  significantly  change  from 
one  run  to  the  next.  So  to  reduce  a  model  year  budget,  we  must  reduce  all  spread 
values  by  the  same  factor.  M-SPARE  reduces  each  model  year  until  all  ratios  are 
near  1. 

The  bottom  of  Exhibit  9-1  displays  the  result  of  multiplying  the  previous  spread 
values  (the  corresponding  top  part  of  the  exhibit)  by  a  “factor”  (third  column)  so  that 
the  resulting  ratios  (cumulative  POP  mark/cumulative  model  budget  —  bottom  row) 
for  the  affected  years  approximately  equals  1.  The  model  starts  with  the  first  year 
(FY98)  and  adjusts  the  factor  until  of  the  appropriate  cumulative  ratios  (FY95,  Fy96, 
and  FY97)  are  greater  than  or  equal  to  1.  Since  the  POP  mark  is  0  in  FY95,  the  factor 
must  equal  0  and  all  spread  values  become  “0”.  The  model  then  moves  to  the  next 
model  year,  looks  at  the  new  ratios,  and  repeats  the  process.  In  some  cases,  the  factor 
is  less  than  0  (i.e.,  the  model  reduced  the  fimds),  and  in  other  cases,  it  is  greater  than 
0  (i.e.,  the  model  increased  the  funds).  The  resulting  ratios  are  never  less  than  1, 
though  sometimes  greater  than  1.  The  latter  assumes  that  NASA  can  apply  POP 
dollars  in  later  years. 

Once  the  ratios  are  approximately  equal  to  1,  the  model  sums  the  current  and 
previous  spread  values  to  produce  the  price  guess  (see  the  shaded  area  of  Exhibit  9-1). 
You  then  rerun  the  model  using  that  price  guess.  For  our  example,  enter  the  price 
guess  values  of  0.1,  21009,  83229,  etc.,  as  the  M-SPARE  price  targets  for  model  years 
FY98,  FY99,  FYOO,  etc.,  respectively.  (You  must  enter  a  target  of  “0.1”  instead  of  a 
“0”  for  FY98  because  M-SPARE  assumes  a  0  means  the  maximum  resource,  and  you 
really  want  a  small  value  to  prevent  the  model  from  selecting  spares.)  Repeating 
that  process  should  produce  budgets  close  to  the  POP  marks  within  a  few  iterations. 
However,  as  you  get  close  to  matching  the  POP  marks,  you  may  need  to  override  the 
price  guess  feature  and  fine  tune  the  estimates  if  the  price  guess  goes  astray. 

DEVELOPMENT  AND  OPERATIONAL  PRODUCT 

The  model  user  may  require  further  breakdown  of  spares  requirements  into 
what  we  term  development  and  operational  spares.  Development  spares  support  the 
station  in  the  first  year  of  an  ORU’s  life,  and  operational  spares  support  the  ORU 
thereafter.  To  estimate  the  split,  the  model  first  calculates  spares  and  budgets 
requirements  as  we  described  in  Chapter  8  (for  this  chapter  section,  we  call  them 
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“aggregate”  requirements).  Then,  it  determines  the  percentage  of  spares  and 
resulting  budget  requirements  associated  with  development.  Finally,  the  model 
subtracts  development  budgets  from  aggregate  budgets  to  estimate  operational 
budgets. 

To  produce  that  disaggregation,  the  user  sets  the  funding  split  option  in  the 
OPTIONS.RPT  file  to  “1”.  The  model  then  produces  two  additional  tables  in  the 
BUDGET.RPT  file  similar  to  the  net  spares  requirements  and  the  spares  budget 
table  (see  Chapter  8)  hut  displays  only  development  spares.  The  following  steps  are 
required  for  the  disaggregation. 

The  M-SPARE  model  first  calculates  total  spares  requirements  over  time  given 
an  availability  or  price  target.  That  calculation  is  standard  for  all  options. 


Next,  M-SPARE  determines  what  portion  of  the  total  spares  are  development 
spares.  Once  each  year,  it  takes  the  ratio  of  the  total  QPA  of  elements  launched 
within  that  year,  to  the  QPA  for  elements  previously  laimched  (the  top  right  and  top 
left  side  of  Exhibit  9-2,  respectively).  M-SPARE  generates  those  tables  (see  QPA 
profile  table  in  OUT.RPT  file)  based  upon  the  element  launch  schedule.  We  assumed 
2  laimches  for  this  ORU  in  Months  3  and  9  for  FY97.  The  element  QPA  for  both 
laimches  equaled  2.  The  shaded  column  in  the  exhibit  is  the  QPA  ratio  for  the  launch 
Month  7.  M-SPARE  uses  that  month  for  the  QPA  ratio  because  it  estimates  gross 
spares  requirements  at  that  month. 


ORU#  1DESICCAN1\S0RBENTBED(CRM)  LofC7ek=  136  NOT  swear  item 
QPA  BY  MONTH  (COU,  YEARS  (ROW) 

1  3  3  4  6  6  7  8  9  10  11  13  Dmlep  133466789  10  11  12  DereL  at  Yr  End  LC  =  7 


1998 

1997 

1998 

1999 

3000 

3001 


0  00000000 
0  02332224 

4  44444444 
4  44444444 
4  44444444 


Deealep  000000000 
DaTtlop  003223224 
Develop  442233220 
Devekip  000000000 
Develop  000000000 


0  0  0  imo 

4  4  4  19000 

0  0  0  04900 
0  0  0 
0  0  0 


444444444444  Develop  0 


00000  000  04900 


Element#  1  3  3  4  6  6  7  8  9  10  11  12  13  14  16 
ElementQPA  3  03000000000  0  0  0 


EXHIBIT  9-2.  ESTIMATING  THE  PROPORTION  OF  DEVELOPMENT  SPARES 
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The  M-SPARE  model  then  multiplies  the  ORU  QPA  ratio  times  the  gross  spares 
requirements  to  estimate  the  development  spares  by  fiscal  year.  That  result  is  given 
in  the  table  that  follows  the  standard  budget  reports  and  is  labeled  development  net 
spares  requirements  (identical  in  format  as  the  aggregate  net  spares  table  discussed 
in  Chapter  8).  The  model  also  ensures  that  the  development  net  spares  does  not 
exceed  the  aggregate  net  spares  requirements. 

For  example,  if  an  ORU  gross  and  net  spares  equals  10  and  4,  respectively,  and 
the  QPA  ratio  equals  0.5,  the  model  assumes  that  50  percent  of  the  gross  spares  (i.e., 
5  spares)  is  for  development.  However,  since  the  model  net  spares  equals  4  for  the 
current  year,  M-SPARE  assumes  that  4  is  the  maximum  number  of  development  net 
spares.  The  model  then  calculates  budgets  by  multiplying  the  development  net 
spares  by  the  ORU  spread  vectors  to  produce  the  development  spares  budgets  table. 

Finally,  the  model  subtracts  the  development  budget,  summed  across  ORUs, 
from  the  aggregate  spares  budget  to  produce  the  operational  budget.  M-SPARE 
displays  the  development,  operational,  and  aggregate  totals  (annual  and  cumulative) 
at  the  bottom  of  the  BUDGET.RPT  file. 
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CHAPTER  10 


THE  WEAR  PREPROCESSOR 


INTRODUCTION 

So  far  we  have  assumed  the  MTBF  specifies  the  likelihood  of  an  ORU  random 
failure.  However,  an  ORU  also  fails  after  being  in  operation  for  some  period  of  time. 
It  simply  wears  out.  The  average  period  of  time  it  takes  to  wear-out  is  the  mean 
“wear”  life  of  an  ORU  and  is  specified  in  the  ORU  data  base  (see  Chapter  5).  For  most 
ORUs,  that  wear  life  is  20  to  30  years;  thus,  they  do  not  wear  out  vdthin  the  model 
time  horizon  of  15  years  (i.e.,  the  maximum  number  of  model  years).  For  some  ORUs, 
however,  the  wear  life  is  shorter  and  related  failures  may  occur  in  the  model  time 
horizon.  For  those  ORUs,  we  use  the  “wear”  preprocessor  to  simulate  both  types  of 
failures  (those  that  are  random  and  those  in  which  an  ORU  wears  out)  and 
automatically  pass  the  aggregate  information  to  M-SPARE. 

The  “wear”  preprocessor,  from  the  M-SPARE  interface  (see  Chapter  2),  selects 
and  prepares  the  proper  ORU  input  data  for  M-SPARE.  It  selects  the  ORU  if  the 
mean  life  of  an  ORU  minus  the  “wear”  wake  (set  in  the  OPTIONS.RPT  file  described 
in  Chapter  6)  is  less  than  the  maximum  number  of  model  years.  For  instance,  if  the 
ORU  has  a  mean  life  of  19  years,  failures  attributable  to  wear  may  occur  as  early  as 
14  years  into  the  ORU  life  (i.e.,  a  “wear”  wake  of  5  years).  Since,  the  maximum 
number  of  model  years  is  15,  failures  from  wearing  out  may  affect  the  model 
calculation,  and  the  preprocessor  is  automatically  used.  You  run  the  wear 
preprocessor  initially  and  again  whenever  you  update  the  ORU  data  base  or  the 
launch  schedule  (in  the  OPTIONS.RPT  file). 

Exhibit  10-1  displays  two  preprocessor  options  once  you  select  the  “Wear” 
option  from  the  M-SPARE  interface.  If  you  select  “Automatic”,  the  preprocessor 
selects  the  proper  ORUs,  generates  the  necessary  input  data,  and  runs  the 
preprocessor.  If  you  select  “Manual”,  the  preprocessor  gives  you  a  chance  to  override 
simulation  input.  It  will  bring  you  directly  to  the  editor  and  the  preprocessor  input 
file  (described  later  in  this  chapter),  allowing  you  to  change  any  of  the  inputs.  When 
finished,  press  the  “ALT-X”  key  combination  to  save  the  file  and  complete  the 


10-1 


execution  of  the  preprocessor.  Before  running  the  manual  option,  you  should  run  the 
automatic  option  once  so  that  the  input  file  is  generated  in  the  proper  format.  Then 
you  can  rim  the  manual  option  and  make  your  edits.  The  purpose  of  the  manual 
option  is  to  allow  you  to  perform  sensitivity  analyses  (such  as  changing  the 
condemnation  assumptions)  with  the  simulation. 


EXHIBIT  10-1.  OPTIONS  FOR  THE  WEAR  PREPROCESSOR 


The  preprocessor  calculates,  by  month,  the  mean  demand  (due  to  random  and 
wear-out  failures),  the  VMR  of  demand,  and  the  cumulative  average  condemnations. 
M-SPARE  automatically  uses  those  data  in  a  multi-ORU  optimization  run  to 
determine  the  spares  mix,  location,  and  budgets.  There  may  be  several  ORU  units 
and  the  number  may  change  over  time  as  SSF  is  built  up.  We  ivill  now  discuss  the 
logic,  inputs,  processing,  and  outputs  of  the  preprocessor. 

PROGRAM  LOGIC 

The  preprocessor  is  a  Monte  Carlo  simulation.  For  each  installed  unit  of  the 
ORU,  the  simulation  uses  an  exponential  probability  distribution  to  estimate  the 
time  of  the  next  random  failure  and  uses  another  probability  distribution  (normal  or 
Weibull)  to  estimate  the  time  the  next  unit  will  wear  out.  The  smaller  time  is 
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selected  as  the  time  of  the  next  failure.  The  simulation  then  determines 
probabilistically  whether  the  failure  can  be  repaired  or  whether  it  must  be 
condemned.  It  is  assumed  there  is  a  probability  (cpj  that  a  random  failure  results  in 
condemnation.  After  N  random  failures  the  tuiit  must  be  condemned.  Of  course,  cp 
may  be  0,  N  may  be  0  (meaning  no  deterministic  condemnation  mode),  or  both  may  be 
0  (the  ORU  is  always  repaired). 

Similarly,  there  is  a  probability  that  a  worn  out  unit  will  be  condemned  and 
after  Af  wear-out  failures  the  unit  must  be  condemned.  Usually  the  cp  that  a  unit  will 
wear  out  is  larger  than  a  random  cp,  and  in  some  cases  (batteries,  for  example)  the 
probability,  cp,  that  a  unit  will  wear  out  is  equal  to  1. 

If  the  first  failure  is  a  random  failure  that  does  not  result  in  a  condemnation, 
the  simulation  then  draws  the  time  to  the  next  random  failure  and  keeps  track  of  the 
fact  that  there  has  been  one  repair  of  a  random  failure.  The  simulation  compares  the 
time  of  the  next  random  failure  to  the  time  the  unit  was  expected  to  wear  out,  selects 
the  smaller  time,  and  repeats  the  procedure  described  above  to  determine  whether 
there  should  be  a  condemnation.  An  analogous  procedure  is  followed  for  a  failure  due 
to  wear  that  does  not  result  in  a  condemnation  and  establishes  a  new  time  that  it  will 
wear  out.  When  the  unit  is  condemned  because  of  a  random  failure  or  because  it  wore 
out,  a  new  unit  of  the  ORU  is  installed  and  the  failure  and  age  counters  are  reset  to  0. 

INPUT 

The  data  for  the  program  is  kept  in  an  ASCII  file  called  PREPIN.DAT 
developed  from  the  MSPAREIN.RPT  and  the  OPTIONS.RPT  files.  The  first  three 
lines  (not  used  by  the  program)  contain  headings  to  assist  the  user  in  identifying  the 
data  elements  on  the  next  line.  Similarly,  the  next  three  lines  (also  not  used  by  the 
program)  contain  headings  to  assist  the  user  in  identifying  the  data  elements  on  the 
succeeding  rows  —  one  row  for  each  ORU. 

A  sample  input  data  file  is  shown  in  Exhibit  10-2.  Note  that  each  ORU 
name/identification  is  assumed  to  be  15  characters  in  length,  but  the  other  fields  may 
be  of  any  length.  The  program  interprets  a  space  as  a  delimiter  between  numeric 
fields.  There  must  be  at  least  one  space  between  fields,  and  a  value  of  0  must  be 
entered  for  a  numeric  value  of  0  (not  blank  as  it  would  be  in  fixed  format  FORTRAN 
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EXHIBIT  10-2.  SAMPLE  INPUT  DATA  FILE 


The  first  line  of  numerical  data  applies  to  all  ORUs  with  each  field  defined  as 
follows: 

•  WEIBULL.  There  are  two  choices  for  the  distribution  of  units  wearing  out: 
“1”  equals  Weibull  (the  M-SPARE  default  assumption)  and  “0”  equals 
normal.  The  same  distribution  is  used  for  all  ORUs,  but  the  parameters  may 
vary  by  ORU. 

•  W/Con.  When  a  value  of  “0”  is  entered,  repairable  item  demand  is  displayed 
in  the  output.  This  is  useful  if  the  user  wants  to  compute  spares  for 
condemnations  separately.  If  a  “1”  is  entered  (the  M-SPARE  default 
assumption),  repairable  demand  is  combined  with  demands  that  result  in 
condenmations  (W/Con).  The  usage  of  this  input  variable  is  discussed  in 
more  detail  in  the  utilization  of  preprocessor  input  in  the  last  section. 

•  Years.  This  is  the  number  of  years  for  which  output  is  desired.  It  is  limited 
to  30  years  or  less.  If  the  number  of  years  of  output  exceeds  the  #Mth  Input 
(described  below),  the  program  assumes  that  the  units  of  each  ORU  (QPA)  in 
the  last  month  remain  constant  until  the  end  of  the  last  year. 

•  Delays.  This  is  the  delay  between  the  time  a  failure  occurs  and  the  time 
when  the  condemnation  determination  is  made. 

•  Seed.  This  is  a  random  number  seed  used  to  draw  failiu’e  times  and  is  an  odd 
number  less  than  32767. 

•  #Reps.  This  is  the  number  of  repetitions  desired  of  the  simulation  for  all 
units  of  the  item.  A  repetition  is  the  number  of  demands  from  0  to  15  years 
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for  all  units  of  the  item.  A  value  of  1000  is  suggested,  but  larger  values 
should  be  used  if  ORUs  have  large  MTBFs. 

•  Print.  This  is  a  print  control  so  that  the  user  can  check  the  program  logic. 
Normally  the  print  detail  switch  is  set  to  “0”  (or  blank).  If  print  equab  “1,” 
the  screen  shows  each  demand  for  each  unit  of  the  ORU,  whether  the 
demand  was  the  result  of  a  random  failure  or  a  worn  out  unit  and  whether  a 
condemnation  resulted.  This  is  done  for  the  first  repetition  of  the  simulation 
on  each  item. 

•  Mth/Period.  The  number  of  months  per  period  is  used  to  combine  monthly 
input  data  into  output  data  by  period. 

•  #Mth  Input.  The  number  of  months  for  which  the  QPA  of  each  ORU  is 
entered  below  in  the  detail  data  by  ORU. 

The  next  inputs  are  for  each  ORU.  The  number  of  ORUs  that  may  be  entered  is 
unlimited,  but  graphs  are  prepared  only  for  the  first  ORU: 

•  NAME.  This  is  any  identification  of  the  ORU  in  a  15-character  field. 

•  MTBF  (Years)  RANDOM.  This  is  the  random  failure  mean  (in  years)  with 
an  exponential  distribution. 

•  MTBF  (Years)  WEAR.  This  input  provides  the  MTBF  (in  years)  caused  by 
wear  for  the  Weibull  or  normal  distribution,  as  specified  in  the  first  data 
element  on  the  top  line.  For  the  Weibull,  this  is  also  called  the  scale 
parameter. 

•  WEAR  SD.  This  is  a  the  standard  deviation  (in  years)  for  the  normal  or  the 
shape  parameter  for  the  Weibull  distribution  of  failures  caused  by  wear. 

•  RANDOM  cp.  This  is  a  random  failure  condemnation  probability,  a  number 
between  0  and  1;  otherwise,  the  ORU  is  repaired. 

•  RANDOM  C#.  This  is  the  number  of  random  failures  before  an  ORU  is 
condemned.  A  value  of  “4”  signifies  that  on  the  fourth  random  failure  of  a 
particular  unit  of  the  ORU  (there  have  been  3  repairs),  it  must  be 
condemned  regardless  of  the  value  of  RANDOM  cp  above.  A  value  of  “0” 
means  that  this  type  of  deterministic  condemnation  does  not  occur. 

•  WEAR  cp.  This  is  the  probability  that  an  ORU  will  be  condemned  because  of 
wearing  out,  a  number  between  “0”  and  “1”;  otherwise,  the  ORU  is  repaired. 

•  WEAR  C#.  This  is  the  number  of  failures  attributable  to  wear  before  a 
condemnation,  similar  to  RANDOM  C#. 
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•  Wgt.  The  weight  of  the  item  used  to  calculate  the  total  weight  per  period  for 
all  ORUs  to  replace  failures  in  orbit.  This  is  the  resupply  weight  needed 
over  and  above  the  initial  spares  requirement. 

•  CUMULATIVE  QPA  #  by  Month.  This  is  the  quantity  of  the  ORU  installed 
at  each  month.  This  should  be  nondecreasing  over  the  months.  (Note  the 
input  specifies  180  months  in  this  example,  and  the  model  develops  these 
data  elements  for  180  months,  not  just  the  10  shown  for  brevity  in 
Exhibit  10-2.)  Exhibit  10-2  data  is  the  QPA  profile  we  discussed  in  Chapter 
4.  In  this  example,  the  QPA  increases  to  18  in  month  13  for  ORU  1  and  to  36 
for  ORU  2. 

PROCESSING 

To  run  the  simulation,  the  M-SPARE  interface  executes  the  preprocessor 
(PREPSIM.EXE)  to  prepare  PREPIN.DAT  data,  the  simulation  (PREP.EXE),  and 
the  plot  program  (PREPPLOT.EXE).  To  move  from  one  plot  to  the  next,  press  the 
“Enter”  key.  To  print  any  graph  on  the  screen,  type  anything  and  press  “Enter”. 
This  allows  you  to  type  labels  if  desired.  The  numeric  screen  output  is  written  to 
OUT.DAT,  and  data  input  for  M-SPARE  is  written  to  PREPOUT.DAT.  Again,  a 
math  co-processor  for  your  computer  is  not  required  but  is  highly  recommended,  as 
the  calculation  will  be  speeded  up  by  a  factor  of  about  10. 

OUTPUT 

The  numerical  output  for  this  example  is  shown  in  Exhibit  10-3.  If  the  input 
random  mean  is  much  smaller  than  the  wear  mean,  the  output  mean  would  equal  the 
random  mean.  The  VMR  would  equal  1  because  the  distribution  is  Poisson.  If  the 
wear  mean  is  much  smaller  than  the  random  mean,  the  output  mean  and  variance 
would  mimic  the  normal  or  Weibull  distribution  input  values.  With  the  sample  ORU, 
the  wear  and  random  means  are  comparable  (e.g.,  4  and  6  years),  so  the  output  mean 
is  less  than  both  (e.g.,  2.8  years)  and  the  VMR  is  less  than  1  (e.g.,  0.92). 

In  the  example,  the  battery  failures  are  dominated  by  wear-out.  That  is  the 
reason  that  the  mean  demand  ~  including  condemnation  demand  —  has  large  peaks 
and  valleys,  and  why  the  VMR  per  period  is  substantially  less  than  1.  Whenever  the 
battery  wears  out  it  must  be  condemned.  This  accounts  for  the  large  fluctuations  in 
annual  condemnations. 

Exhibit  10-3  also  shows  the  average  demand  per  unit  and  the  maximum 
demand  per  unit.  Though  not  displayed,  the  simulation  also  estimates  the  weight 


10-6 


r 

Number  of  months/period^ 

1 

BATTERY  ORU 

Fall 

Time  Mean* 

4.4966  Var« 

1. 

0474 

MEAN 

DEMAND 

1  PER  PERIOD  INCLUDING 

CONDEMNATIONS 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

0 

0.05 

0.05 

0.04 

0.05 

0.05 

0.06 

0.04 

0.04 

0.05 

0.05 

1 

0.04 

0.05 

0.07 

0.06 

0.05 

0.06 

0.05 

0.08 

0.06 

0.06 

2 

0.06 

0.06 

0.07 

0.06 

0.12 

0.07 

0.10 

0.10 

0.09 

0.10 

3 

0.10 

0.08 

0.12 

0.12 

0.12 

0.12 

0.13 

0.16 

0.17 

0.19 

4 

0.21 

0.22 

0.24 

0.29 

0.34 

0.38 

0.45 

0.56 

0.61 

0.71 

5 

0.74 

0.86 

0.95 

1.14 

1.17 

1.36 

1.41 

1.52 

1.52 

1.62 

6 

1.61 

1.57 

1.47 

1.43 

1.29 

1.22 

1.11 

1.09 

1.04 

0.93 

! 

1 

7 

0.87 

0.94 

0.90 

0.96 

0.99 

1.00 

1.03 

0.99 

1.02 

1.05 

1 

! 

8 

1.09 

1.07 

1.03 

1.05 

1.09 

1.04 

0.96 

0.89 

0.77 

0.69 

9 

0.57 

0.55 

0.41 

0.38 

0.39 

0.38 

0.35 

0.35 

0.41 

0.43 

10 

0.46 

0.50 

0.56 

0.60 

0.62 

0.69 

0.71 

0.78 

0.88 

0.87 

11 

0.98 

1.05 

1.04 

1.15 

1.07 

1.23 

1.18 

1.22 

1.21 

1.19 

VARIANCE/MEAN  DEMAND  PER 

PERIOD 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

0 

1.04 

0.99 

1.06 

0.95 

1.07 

0.97 

0.96 

0.96 

1.00 

0.95 

1 

1.00 

1.02 

1.02 

1.01 

1.03 

1.00 

0.95 

0.95 

1.06 

0.97 

2 

0.94 

0.98 

1.03 

1.00 

1.04 

1.04 

0.99 

0.99 

1.01 

0.92 

3 

0.96 

0.94 

0.97 

0.95 

1.07 

1.09 

0.95 

1.03 

0.99 

1.03 

4 

0.97 

0.97 

0.97 

1.07 

0.89 

1.03 

0.91 

1.01 

0.95 

0.88 

5 

1.01 

0.90 

1.00 

0.89 

0.99 

0.93 

0.98 

0.92 

0.97 

0.91 

6 

0.92 

1.01 

0.96 

0.92 

1.01 

0.87 

1.03 

0.92 

0.94 

0.99 

7 

0.92 

0.91 

0.96 

1.01 

0.91 

1.02 

0.95 

0.92 

0.92 

0.97 

8 

0.98 

0.92 

0.91 

0.99 

0.91 

0.95 

0.89 

0.94 

0.94 

1.00 

9 

0.98 

0.97 

1.00 

0.97 

0.98 

0.97 

0.97 

0.98 

0.99 

1.12 

10 

1.05 

0.94 

0.96 

0.96 

1.00 

0.98 

0.98 

0.99 

0.92 

0.97 

j 

11 

0.96 

1.02 

0.96 

0.99 

1.04 

0.97 

0.95 

1.03 

0.89 

0.91 

Period  Mean 

»  0. 

6158 

V/M= 

0.9600 

Aver 

demand/un1t* 

0.0130  Max  demand/unit* 

0. 

0336 

Max  Period*  60 

CUMULATIVE 

AVERAGE 

:  CONDEMNATIONS  BY  PERIOD 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

0 

0.05 

0.09 

0.14 

0.18 

0.23 

0.29 

0.33 

0.37 

0.41 

0.46 

1 

0.50 

0.56 

0.63 

0.69 

0.74 

0.80 

0.85 

0.92 

0.98 

1.04 

2 

1.11 

1.16 

1.24 

1.30 

1.42 

1.49 

1.59 

1.69 

1.78 

1.88 

3 

1.99 

2.07 

2.18 

2.30 

2.42 

2.54 

2.66 

2.82 

2.99 

3.18 

4 

3.40 

3.62 

3.86 

4.15 

4.49 

4.87 

5.32 

5.88 

6.49 

7.20 

5 

7.94 

8.80 

9.75 

10.89 

12.07 

13.42 

14.83 

16.35 

17.87 

19.49 

6 

21.09 

22.66 

24.13 

25.56 

26.85 

28.07 

29.18 

30.27 

31.30 

32.24 

7 

33.11 

34.04 

34.95 

35.90 

36.89 

37.89 

38.92 

39.91 

40.93 

41.98 

8 

43.07 

44.14 

45.17 

46.22 

47.32 

48.35 

49.32 

50.21 

50.98 

51.67 

9 

52.24 

52.79 

53.20 

53.58 

53.97 

54.35 

54.70 

55.06 

55.47 

55.89 

10 

56.35 

56.85 

57.41 

58.01 

58.63 

59.31 

60.03 

60.81 

61.69 

62.56 

11 

63.53 

64.58 

65.63 

66.78 

67.85 

69.08 

70.26 

71.49 

72.70 

73.89 

STANDARD  DEVIATION  OF  CUMULATIVE 

CONDEMNATIONS 

;  BY  PERIOD 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

0 

0.22 

0.31 

0.38 

0.43 

0.49 

0.55 

0.59 

0.62 

0.66 

0.70 

1 

0.73 

0.77 

0.83 

0.88 

0.91 

0.95 

0.97 

1.01 

1.03 

1.05 

2 

1.08 

1.11 

1.14 

1.18 

1.23 

1.25 

1.30 

1.34 

1.38 

1.41 

3 

1.44 

1.46 

1.49 

1.52 

1.55 

1.59 

1.62 

1.61 

1.65 

1.70 

4 

1.76 

1.79 

1.86 

1.90 

1.94 

2.00 

2.13 

2.24 

2.33 

2.47 

5 

2.58 

2.65 

2.75 

2.79 

2.85 

2.94 

2.97 

3.00 

3.07 

3.01 

6 

2.98 

2.90 

2.79 

2.71 

2.86 

2.60 

2.50 

2.49 

2.44 

2.46 

7 

2.56 

2.57 

2.59 

2.56 

2.57 

2.64 

2.68 

2.74 

2.79 

2.76 

8 

2.77 

2.86 

2.84 

2.79 

2.73 

2.69 

2.60 

2.54 

2.42 

2.38 

9 

2.34 

2.30 

2.29 

2.29 

2.35 

2.39 

2.44 

2.53 

2.57 

2.65 

10 

2.72 

2.76 

2.81 

2.86 

2.93 

2.98 

3.04 

3.14 

3.23 

3.30 

11 

3.36 

3.42 

3.46 

3.48 

3.49 

3.47 

3.40 

3.41 

3.38 

3.39 

\ _ 

_ J 

EXHIBIT  10-3.  OUTPUT  FOR  BATTERY  ORU 


10-7 


required  per  period  to  replace  repairable  failures  and  condemnations  on  orbit  for  all 
ORUs  that  have  been  processed. 

Exhibit  10-4  shows  the  failure  rate  plot,  m(t),  for  a  Battery  ORU  unit  that  is 
connected  to  the  probability  distribution  of  time  to  failure,  f(t),  by  the  equation: 


m(t)  = 


lit) 


[Eq.  10-1] 


where  F(t)i3  the  cumulative  distribution  of  the  probability  density,  fit)  from  0  to 

Exhibits  10-5  to  10-7  display  battery  ORU  plots  for  the  following: 

•  The  probability  distribution  of  time  to  failure  for  a  unit. 

•  The  mean  demand  per  year  for  all  units,  including  those  that  result  in 
condemnation. 

•  The  annual  condemnations  for  all  units  (not  the  cumulative  as  in  the 
numeric  output  above).  (The  first  peak  in  the  condemnation  plot  is  at  about 
5  years  -  near  the  wear-out  lifespan  of  the  battery.) 

Exhibit  10-8  shows  the  shuttle  weight  requirement  for  resupply  per  period  for 
all  wear-out  ORUs  to  replace  all  on-orbit  failures  of  any  type. 

UTILIZATION  OF  PREPROCESSOR  OUTPUT 

The  output  from  the  preprocessor  may  be  used  for  three  different  purposes: 
budget,  prociirement,  and  shuttle  manifests.  Depending  on  the  purpose,  the  user 
may  want  to  separate  the  condemnation  output  from  the  repairable  demands 
(W/Con=0  in  the  input),  particularly  if  multiple  years  of  condemnations  are  bought 
at  one  time.  On  the  other  hand,  if  condemnations  are  replaced  by  orders  placed  at  the 
time  of  failure,  it  is  more  appropriate  to  combine  condemnation  demand  and 
repairable  demands  (W/Con=l).  This  is  the  assumption  M-SPARE  uses.  To  allow 
the  user  maximum  flexibility,  we  have  provided  the  capability  to  combine  the 
condemnation  and  repairable  demand  output  or  keep  them  separate. 

Integration  with  M-SPARE 

The  M-SPARE  model  uses  most  of  the  monthly  simulation  output  presented  in 
Exhibit  10-3  to  estimate  an  ORU’s  mean  on-orbit  failures,  mean  serviceables 
(broken)  spares,  replaced  condemnations,  and  the  VMR.  The  VMR  value  is  the 
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EXHIBIT  10-6.  DEMANDS  PER  MONTH 
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EXHIBIT  10-8.  WEIGHT  PER  MONTH 


monthly  value  at  the  launch  month.  M-SPARE  also  calculates  other  variables  at  the 
launch  month.  For  those,  M-SPARE  looks  back  to  determine  the  number  of 
unserviceables  and  replaced  condemnations.  It  also  looks  forward  tc  determine  what 
fails  on  the  station  in  the  next  cycle.  The  equations  are  very  similar  in  format  to 
Equations  4-6  to  4-10,  except  instead  of  summing  monthly  QPA  values  the  model 
sums  the  appropriate  demand  values  from  the  simulation. 

The  four  key  demand  values  are  total  demand  (TD)  —  the  mean  demand 
subtable  in  Exhibit  10-3;  cumulative  condemnations  (CC)  —  the  third  subtable  in 
Exhibit  10-3;  condemnation  demands  (CD)  —  the  difference  in  successive-year 
values  of  the  cumulative  demands;  and  repair  demand  (RD)  —  the  difference  of  total 
minus  condemnation  demand.  Equations  10-2  to  10-8  estimate  mean  broken  spares, 
mean  orbit  failures,  and  replaced  condemnations. 

3 

MB(yr)  =  B/.  [Eq.  10-2] 

/=l 
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RIX.m). 


[Eq.  10-3] 


p  LM^-l 

^1  +  ^2  m=LM{yr)-MMi 


F2  LMip^-l 

^2  ~  p  p  ^  RlXm). 

^1  +  ^2  m=lMyr)-MM2 


IMM-l 

B3  =  2I  ClXm). 

m  =  LM(yr)— UMi 

LM(yr)+MLC-l 
MCXyr)  =  JZ 

m  =  LM(yr) 


CRCiyr)  =  ^  CC(yr)  -  B3Cyr)J 


[Eq.  10-4] 


[Eq.  10-5] 


[Eq.  10-6] 


[Eq.  10-7] 


where 

A 

m 

I 

F 

MM 

NLC 


RC(yr)  =  CRCiyr)  -  CRCiyr  -  1). 


[Eq.  10-8] 


=  mean  orbit  failures  per  month 

=  1,2,...  (year  X  12),  where  year  is  the  number  of  model  years  the 
user  specifies  (see  Chapter  6) 

=  maintenance  levels  ( 1  =  KSC,  2 = prime/OEM,  3 = condemnations) 
=  fraction  of  total  failures  entering  each  maintenance  level 
=  maintenance  months  =  NLC  X  MLC 
=  number  of  logistics  cycles  in  the  entire  maintenance  time 


_  I  LogCycU  (days repair  or  replace  (days) 
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LogCycle  {days) 
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[] 

MLC 


LM(yr) 

yr 

RC 

CRC 


=  largest  integer  value,  i.e.,  truncate  real  into  an  integer  value 
=  Months  in  a  LogCycle 

LogCycle  (days) 

30  {daya!  month) 

=  launch  month,  calculation  point  of  spares  requirements,  assumes 
that  it  is  one  LogCycle  from  end  of  fiscal  year 

=  (yrxl2)  -MLC-1 

=  model  year 

=  replaced  condemnations 

=  cumulative  replaced  condemnations. 
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APPENDIX  A 


SPARES  OPTIMIZATION  PROOF 


The  Multiple  Spares  Prioritization  and  Availability  to  Resource  Evaluation 
(M-SPARE)  model  is  based  upon  a  marginal-analysis  approach.  Spares  are  ranked  in 
order  of  decreasing  benefit  per  cost  and  added,  in  that  order,  to  the  inventory  until  a 
target  resource  expenditure  or  station  availability  is  reached.  This  appendix  proves 
that  the  marginal-analysis  technique  generates  the  optimal  spares  solution;  that  is, 
no  spares  solution  set  produces  a  greater  availability  for  the  same  cost  or  produces 
equal  availability  for  less  cost.! 

From  Equation  3-1  of  the  main  text,  station  availability  is  defined  as 

A  =  atation  availability  =11  PSN^  («i  )  ,  [Eq.  A-1] 

t 

where  probability  of  a  spare  when  needed  {PSNO  isj)  is  the  probability  that  a  spares 
level  of  Si  is  sufficient  for  ORUi  over  the  station  logistics  cycle,  i.e.,  that  the  number  of 
demands  over  the  cycle  is  less  than  or  equal  to  si. 

We  want  to  maximize  Equation  A-1  subject  to  a  cost  constraint.  An  equivalent 
problem  is  to  maximize  the  logarithm  of  Equation  A-1  because  a  function  and  its 
logarithm  achieve  their  maximum  at  the  same  point.  Since  the  logarithm  of  a 
product  is  the  sum  of  the  logarithms,  this  converts  the  objective  function  into  an 
additive  separable  function  of  the  orbital  replaceable  unit  (ORU)  probabilities: 

ln{A)  =  Iniatation  availability)  =^  In  [  PSNj{  Sj )  ] ,  [Eq.  ^-2] 


^Further  discussion  of  these  and  related  issues  can  be  found  in  LMI  Report  AF201,  The  Aircraft 
Availability  Model:  Conceptual  Framework  and  Mathematica,  T.  J.  O’Malley,  June  1983  and 
Craig  C.  Sherbrooke,  Optimal  Inventory  Modeling  of  Systema:  Multi-Echelon  Techniquea,  New  York: 
Wiley,  to  be  published  in  September  1992. 


Denote  the  benefit  per  cost  ratio  of  buying  the  nth  spare  of  ORUi  by  r(i,n).  Then, 


=  InPSNjjn)  -  lnPSNi(n-l) 

f 

Ci 


[Eq.  A-3] 


where  ci  is  the  cost  of  ORUi.  We  will  sometimes  simply  refer  to  r(s)  when  the  exact 
values  of  i  and  n  are  immaterial.  The  marginal  analysis  algorithm  in  M-SPARE 
sorts  the  ORU  spares  in  terms  of  r(i,nX  which  we  will  call  the  sort  value.  We  wish  to 
show  that  buying  in  this  order  is  optimal. 

We  first  note  that  for  this  procedure  to  even  make  sense.  In  PSN  must  be 
convex,  i.e.,  r  must  be  a  decreasing  function  of  spares  level  for  each  ORUi;  otherwise, 
one  could  be  led  to  the  meaningless  situation  of,  say,  wanting  to  buy  the  third  spare  of 
an  ORU  before  buying  the  first  spare.  This  is  physically  nothing  more  than  the  law  of 
diminishing  returns  for  spares  —  each  additional  spare  is  worth  less  than  (or  equal 
to)  the  one  preceding  it. 

We  will  show  that  r  is  decreasing  in  the  case  of  a  Poisson  failure  process.  The 
same  approach  can  be  used  in  the  case  where  failures  are  distributed  according  to  the 
binomial  or  negative  binomial  distribution. 

Let 


[Eq.  A-4] 


represent  the  (Poisson)  probability  of  x  unserviceable  items  in  resupply  and  where  X 
represents  the  mean  number  of  unserviceables  in  resupply.  Then 

$ 

PSN(s)  =  X)  p(x).  [Eq.  A-5] 

x=0 


It  is  enough  to  show  that,  for  all  s. 

In  PSN(8)-  In  PSN(8  -l)^  In  PSN(8  +  l)-ln  PSN(8)  [Eq.  A-6] 
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Equation  A-6  is  equivalent  to 


g=0 
«— 1 

x=0 


«  +  l 

E  p(*) 
»=0 

t  PM 


E  p<*)  E  pM 

*=o  *=o 


*— 1 

E  p(*> 
*=0 

E  prx> 
1=0 

1+P(8) 

l+p(8  +  l) 

-  * 

E  p(*)  E  p<*) 

*=0  *=0 

p(8) 

p(8+l) 

8—1 

E  p<*) 
*=0 

Ep(x) 

*=0 

a  9  M. 

p(8)E  p(*)2p(«+i)E  p<*> 


A*  L-^ 


Substituting  p(x)  =  I  —  jc  in  the  above  yields, 


—  e-^E  — 2-E!^e“^E  — e"^ 

a!  *=o  (•+!)!  x=o  *'• 


[Eq.  A-7] 


[Eq.  A-8] 


[Eq.  A-9] 


[Eq.A-10] 


[Eq.  A-11] 


[Eq.  A-12] 


[Eq.  A-13] 


*  l*  +  «  »~1  \»  +  l+x 

V  ± i _ 

alx!  x=o  (s+1)!*! 


X*  .-1 

—  +  E  - ^  E 

si  x=0  st(x+l)!  1=0 


^.+x+l 


(s+l)!x! 


[Eq.  A-14] 


Since  x+l  s  s+1,  each  of  the  terms  in  the  left-hand  summation  exceeds  the 
corresponding  term  in  the  right-hand  summation.  Thus,  the  inequality  holds,  PSN  is 
convex,  and  the  sort  value  is  indeed  a  decreasing  fxmction  of  spares  level. 

If  Af  is  any  set  of  spares,  we  will  denote  by  M(i)  the  number  of  spares  of  ORU(i) 
in  the  set  M,  by  A(M)  the  resulting  station  availability,  and  by  C{M)  the  cost  of 
procuring  the  spares  in  Af.  We  have: 


A(M)  =  IlPSJVii  +  l  ] 

t 

C(M)  =  Y.  CiMii), 


[Eq.  A-15] 


[Eq.A-16] 


where  Ci  is  the  cost  of  ORUi. 

If  we  increase  the  level  of  ORUj  from  M{j)  to  Mij)  -[■  1  to  form  a  new  spare  set  Af  '» 

then 


In  Aim  =  5^  InPSNii  1  +  InPSNji  M(j)  +  l]  [Eq.  A-171 

i*J 

=  E  InPSNi  [«(*)]  -I-  InPSNji  Af(;‘)  +  1  ]  -InPSNji  ] 
i 

=  lnA(.M)+ Cjr[j,M(j)-¥l]. 

That  is,  adding  a  spare  s  with  cost  c(s)  to  the  set  M  gives  a  new  availability  A{M'), 
with  lnA{M')  =  lnA{M)-\-c{s)  r(s). 
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In  general,  adding  any  number  of  spares  to  Af  to  form  M’  results  in  a  new 
availability  and  the  similar  relationships 


In  Aim  =  ZnA(Af)+  51  c(«)Ks), 

aiM'-M 


[Eq.  A-18] 


where  M'  —  M  denotes  the  difference  of  the  sets  M'  and  Af,  the  collection  of  spares  that 
were  added. 


Now  suppose  that  the  set  M  was  obtained  via  marginal  analysis,  and  let  N  be 
any  other  set  of  spares  with  lower  or  equal  total  cost,  C{N)  s  C{M).  To  show  M  is 
optimal,  we  must  show  that  A{N)  ^  A(Af)  or,  equivalently.  In  A{N)  s  In  AiAf). 

Let  X  =  N^M,  the  intersection  of  N  and  Af.  Then  X  contains  the  spares  common 
to  both  sets  A/ and  N.  By  the  above,  we  have 


InA(M)  =  lnA(X)  +  51  dsMs)  [Eq.  A-19] 

a^M-X 


InAiN)  =  InAiX)  +  51  c(a)r(a).  [Eq.A-20] 

s^N-X 

The  marginal-analysis  technique  dictates  that  Af  contains  all  of  the  highest  sort 
values.  Therefore,  since  M—X  and  N—X  are  disjoint,  we  know  that  the  lowest  sort 
value  r(M)  of  spares  in  M—X  is  greater  than  the  greatest  sort  value  r(N)  of  a  spare  in 
N—X.  Further,  since  C(M)  2  C(N),  C(M—X)  2  C(N—X).  Thus, 


/rtA(M)  =  lnA(X)+  51  cfsMa)  [Eq.  A-21] 

a^M-X 

>lnA(X)+r(M)  51 

a(^M-X 


2  lnA(X)+  r<Af)C(Af-X) 


2  lnA(XJ+r(NJCfJ^-X} 

2  In  AfX)+  r(N)  51  da) 
a^N-X 

2  lnA(X)+  51  dajiia) 
8(N-X 


=  InA(N). 


Thus,  M  is  an  undominated  set  of  spares,  and  the  optimality  of  marginal 
analysis  is  proved. 
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GLOSSARY 


Ascn 

= 

American  Standard  Code  for  Information  Interchange 

CAGE 

Commercial  and  Government  Entity 

CRC 

= 

cumulative  replaced  condenmations 

DOS 

= 

Disk  Operating  System 

EPS 

= 

electric  power  system 

FSCM 

= 

Federal  Supplier  Code  for  Manufactures 

IBM 

= 

International  Business  Machines 

KSC 

Kennedy  Space  Center 

LC 

= 

LogCycle 

LM 

= 

launch  month 

LMI 

= 

Logistics  Management  Institute 

M-SPARE 

= 

Multiple  Spares  Prioritization  and  Availability  to  Resource 
Evaluation 

MB 

= 

mean  broken 

MTBF 

= 

mean  time  between  failures 

NASA 

= 

National  Aeronautics  and  Space  Administration 

OEM 

= 

original  equipment  manufacturer 

ORU 

— 

orbital  replaceable  unit 

PC 

— 

personal  computer 

PLT 

— 

procurement  lead  time 

POP 

— 

Program  Operating  Plan 

POS 

= 

peacetime  operating  stock 

PSN 

= 

probability  of  a  spare  when  needed 

QPA 

= 

quantity  per  application 

B-3 


RAM 

RMAT 

SIMSYLS 

SSF 

VMR 


Random  Access  Memory 

Reliability  and  Maintainability  Assessment  Tool 
Simulation  of  Manned  Space  Station  Logistics  Support 
Space  Station  Freedom 
variance-to-mean  ratio 
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